Письма с превышением уплаты за год

[vk65]

К сожалению, именно на последней версии 1.1.8 !

Интересно было бы посмотреть на исходные данные, с которыми получается такой результат. В предыдущих версиях могли быть ситуации, когда сравниваются, к примеру, 463000 и 463000.002, естественно, они не равны, но в файл выводилось значение с 2 знаками (463000 # 463000.00). После добавления округления до 2 знаков перед сравнением такие ситуации должны были исчезнуть.

[yante]

Предлагаю определиться с возможными погрешностями (математически). Как определимся, будет новая версия. В разделе "Известные ошибки и особенности" информация на этот счёт есть.

Пусть сперва ПФР определится, а потом уж и мы будем определяться
Думаю, что в программу можно было бы добавить флаг "Набивалки"/"Бухпрограммы", чтобы при проверке суммы считались по-разному ( формулы для разных случаев приводились в соседней теме на форуме )

[LoraK]

Цитата:
Кстати, есть еще и такая ошибка : "463000 # 463000.00"
Это получено на последней версии? В 1.1.8 такой ошибки быть не должно.

К сожалению, именно на последней версии 1.1.8 !

Кстати, если Вы посчитаете накопительную нарастающим итогом (а меня тут недавно убеждали со ссылкой на 212-ФЗ, что правильно - только так), то эта копейка уйдёт.

В текущем квартале считаю НЕ нарастающим итогом, а в процентах от облагаемой базы.
Не экспериментировала пока, но боюсь, что в этом случае не будет выдержано контрольное соотношение 20/6 в текущем квартале при проверке ЧЕКом, увы ...

Предлагаю определиться с возможными погрешностями (математически). Как определимся, будет новая версия. В разделе "Известные ошибки и особенности" информация на этот счёт есть.

Соглашусь с vk65 о пороговом значении допустимой погрешности в 2 коп.

[vk65]

А можете объяснить, почему 1,92 коп.?

Даже не 1.92 коп, а 2 коп, если округлить. Посмотрите файл.

Может, мне есть смысл не выдавать ничего при укладке в погрешность?

Можно выбрать пороговое значение погрешности, например 2 коп * кол-во периодов, и выдавать либо предупреждение, либо ошибку.
Хотя, как уже говорилось выше, если страхователь будет считать взносы по нарастанию и при расчете стр/нак применять один из вариантов, обсуждавшихся в соседней ветке (например, нак = 26% - стр), погрешности не будет вообще.

[lubezniy]

Наконец-то сдали отчетность и появилось время посмотреть Вашу программу, Виктор. В целом, понравилось. Только ожидалось, что в графе "номер файла" будет не порядковый номер файла при загрузке (по протоколу), а номер пачки (из имени файла). Но это не критично. Вопрос в другом - про превышение 463000.

По кварталам 2011 года:
облаг = 177551.78 + 179115.25 + 106332.97 = 463000.00
страх = 35510.36 + 35823.05 + 21266.59 = 92600.00
накоп = 10653.11 + 10746.92 + 6379.98 = 27780.01

В итоге - ошибка, что 463000 # 463000.04 (= (92600 + 27780.01)/0.26)
Кстати, есть еще и такая ошибка : "463000 # 463000.00"
Понятно, что погрешность округления.
Но что мне делать? Превышение накопительной на 1 копейку - это криминал? Теперь подавать корректировку?

Предлагаю определиться с возможными погрешностями (математически). Как определимся, будет новая версия. В разделе "Известные ошибки и особенности" информация на этот счёт есть.

[lubezniy]

Эта проблема обсуждалась выше. Максимальная погрешность восстановления базы в одном периоде составит 0.5/0.26=1.92коп.

А можете объяснить, почему 1,92 коп.? Может, мне есть смысл не выдавать ничего при укладке в погрешность?

[vk65]

Только ожидалось, что в графе "номер файла" будет не порядковый номер файла при загрузке (по протоколу), а номер пачки (из имени файла). Но это не критично.

Номера пачек могут повторяться, а номера файлов - уникальны. Тем более, номер пачки по номеру файла можно смотреть в шапке.

В итоге - ошибка, что 463000 # 463000.04 (= (92600 + 27780.01)/0.26)

Эта проблема обсуждалась выше. Максимальная погрешность восстановления базы в одном периоде составит 0.5/0.26=1.92коп.

Кстати, есть еще и такая ошибка : "463000 # 463000.00"

Это получено на последней версии? В 1.1.8 такой ошибки быть не должно.

Понятно, что погрешность округления.
Но что мне делать? Превышение накопительной на 1 копейку - это криминал? Теперь подавать корректировку?

Считать такие случаи ложными срабатываниями.
Кстати, если Вы посчитаете накопительную нарастающим итогом (а меня тут недавно убеждали со ссылкой на 212-ФЗ, что правильно - только так), то эта копейка уйдёт.

[Валерий Ж]

блин, забыл про эту ссылку, спасибо, но превышение 463000,04 при проверке мы например игнорим, так как понятно, что это

[LoraK]

речь идет о новом Чеке, если да где взяли новую сборку, в разделе скачать от 12.10.2011 или о другой проге?

Речь идет об обсуждаемой здесь программе Виктора Любезного VL:СверкаПФ, Версия 1.1.8.0 от 30.10.2011 г. http://www.lubezniy.ru/soft/vlsverkapf/ (этот модуль включен в ЧЕК, правда, в последней версии ЧЕКа от 12.10.2011 - старая версия 1.1.5.0 )

[Валерий Ж]

П.С. Версия от 30.10.2011

речь идет о новом Чеке, если да где взяли новую сборку, в разделе скачать от 12.10.2011 или о другой проге?

[LoraK]

Ошибка при проверке: "Ошибка: 3/2011 - превыш. базы: 463000.00 р". Пересчитал сам - начисления сделаны из расчета 463000.

Наконец-то сдали отчетность и появилось время посмотреть Вашу программу, Виктор. В целом, понравилось. Только ожидалось, что в графе "номер файла" будет не порядковый номер файла при загрузке (по протоколу), а номер пачки (из имени файла). Но это не критично. Вопрос в другом - про превышение 463000.

По кварталам 2011 года:
облаг = 177551.78 + 179115.25 + 106332.97 = 463000.00
страх = 35510.36 + 35823.05 + 21266.59 = 92600.00
накоп = 10653.11 + 10746.92 + 6379.98 = 27780.01

В итоге - ошибка, что 463000 # 463000.04 (= (92600 + 27780.01)/0.26)
Кстати, есть еще и такая ошибка : "463000 # 463000.00"
Понятно, что погрешность округления.
Но что мне делать? Превышение накопительной на 1 копейку - это криминал? Теперь подавать корректировку?

П.С. Версия от 30.10.2011
П.П.С. А что изменилось в CHECKXML+ (версия от 24.10, а последние изменения - от 17.10) ?

[lubezniy]

Если погрешность округления при одном вызове составит 0.5 коп, то за 4 вызова для 2011 г. - 2 коп.

Это как раз понятно. Я имею в виду - насколько теперь хватит точности расчётов вблизи предельного значения, чтобы свести погрешности к минимуму.

В <TopRowBottomPane> ставится номер строки, которая будет видна после разделителя, нумерация с нуля. У Вас закреплено 3 строки, после разделителя показывается пятая, четвёртую не видно. В принципе, значение <TopRowBottomPane> нужно делать больше, чем <SplitHorizontal>, если, например, есть длинная таблица с итогами внизу и хочется, чтобы итоги сразу были бы видны. В остальных случаях лучше делать эти значения равными.

Ай спасибо. Теперь стало понятно полностью и смотреться совсем хорошо. Скорректировал, версию обновил.

Я бы в <SplitVertical> и <LeftColumnRightPane> поставил 2 вместо 5. Хотя это не очень принципиально, границы легко меняются двумя-тремя щелчками мышки.

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

[vk65]

Сложно сказать насчёт округлений,

Если погрешность округления при одном вызове составит 0.5 коп, то за 4 вызова для 2011 г. - 2 коп.

а разделение после указанного стало реально смотреться гораздо лучше.

В <TopRowBottomPane> ставится номер строки, которая будет видна после разделителя, нумерация с нуля. У Вас закреплено 3 строки, после разделителя показывается пятая, четвёртую не видно. В принципе, значение <TopRowBottomPane> нужно делать больше, чем <SplitHorizontal>, если, например, есть длинная таблица с итогами внизу и хочется, чтобы итоги сразу были бы видны. В остальных случаях лучше делать эти значения равными.

А вот тут пока не получилось придумать ничего, кроме некоторого пересмотра ширины ячеек (в выложенной версии скорректировано).

Я бы в <SplitVertical> и <LeftColumnRightPane> поставил 2 вместо 5. Хотя это не очень принципиально, границы легко меняются двумя-тремя щелчками мышки.

[lubezniy]

Вы ещё добавили округление в процедуре GetNU. Лучше убрать, т.к. именно здесь могут появиться ошибки округления. Вполне достаточно округления при сравнении с MaxBase.

Должно быть примерно так:
Обратите внимание: <SplitHorizontal> не должно превышать <TopRowBottomPane>, а <SplitVertical> - <LeftColumnRightPane>.

Эти два момента исправлены. Выложил внеочередную версию. Сложно сказать насчёт округлений, а разделение после указанного стало реально смотреться гораздо лучше. Спасибо.

И ещё - лучше закреплять не более 2 - 3 колонок, т.к. в настоящее время закреплённая область занимает более половины экрана, неудобно просматривать остальные данные.

А вот тут пока не получилось придумать ничего, кроме некоторого пересмотра ширины ячеек (в выложенной версии скорректировано).

[vk65]

пришлось ограничиться округлением перед проверкой. Посмотрим, насколько надёжно получится так.

Вы ещё добавили округление в процедуре GetNU. Лучше убрать, т.к. именно здесь могут появиться ошибки округления. Вполне достаточно округления при сравнении с MaxBase.

Жду конкретных советов по исправлению XML-кода в этой части.

Должно быть примерно так:

  <WorksheetOptions xmlns="urn:schemas-microsoft-com:office:excel">
   <Selected/>
   <FreezePanes/>
   <FrozenNoSplit/>
   <SplitHorizontal>3</SplitHorizontal>
   <TopRowBottomPane>3</TopRowBottomPane>
   <SplitVertical>5</SplitVertical>
   <LeftColumnRightPane>5</LeftColumnRightPane>
   <ActivePane>0</ActivePane>
   <Panes>
    <Pane>
     <Number>0</Number>
     <ActiveRow>0</ActiveRow>
     <ActiveCol>0</ActiveCol>
    </Pane>
   </Panes>
  </WorksheetOptions>

Обратите внимание: <SplitHorizontal> не должно превышать <TopRowBottomPane>, а <SplitVertical> - <LeftColumnRightPane>.
И ещё - лучше закреплять не более 2 - 3 колонок, т.к. в настоящее время закреплённая область занимает более половины экрана, неудобно просматривать остальные данные.