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

[lubezniy]

Я сейчас попробовал - браузер реагирует на этот код так же, как и на < br >

Firefox чуть кривит при отображении, но не критично. Версия обновлена.

[ВасилийНиколаевич]

...

Предлагаю внести небольшое изменение в работу программы, результатом которого будет список "забытых" ЗЛ (ТЗ прилагается).

[lubezniy]

Предлагаю внести небольшое изменение в работу программы, результатом которого будет список "забытых" ЗЛ (ТЗ прилагается).

Суть примерно понятна. С реализацией есть некоторые сложности, но в целом вопрос решаемый. Буду думать.

[ВасилийНиколаевич]

Суть примерно понятна. С реализацией есть некоторые сложности, но в целом вопрос решаемый. Буду думать.

Спасибо за внимание

[ВасилийНиколаевич]

Ошибка при проверке: "Ошибка: 3/2011 - превыш. базы: 463000.00 р". Пересчитал сам - начисления сделаны из расчета 463000. Архив с ИС за 2011 прилагается (кол-во ЗЛ в ИС сокращено до одного).

[lubezniy]

Ошибка при проверке: "Ошибка: 3/2011 - превыш. базы: 463000.00 р". Пересчитал сам - начисления сделаны из расчета 463000. Архив с ИС за 2011 прилагается (кол-во ЗЛ в ИС сокращено до одного).

Подтверждаю. Как только выясню и устраню причину, выложу новую версию.
UPD: Причину выяснил: баг с округлением при делении суммы начисленных взносов нарастающим итогом с начала года на ставку (почему-то выплыла одна сотая копейки). Думаю, почему так и как устранить.

[lubezniy]

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

[vk65]

Причину выяснил: баг с округлением при делении суммы начисленных взносов нарастающим итогом с начала года на ставку (почему-то выплыла одна сотая копейки). Думаю, почему так и как устранить.

Можно перед проверкой на превышение округлить до 2 знаков после запятой. Я попробовал, после этого пример из вышеуказанного архива проверяется без ошибок.

[lubezniy]

Можно перед проверкой на превышение округлить до 2 знаков после запятой. Я попробовал, после этого пример из вышеуказанного архива проверяется без ошибок.

Можно банально на базу поставить тип real вместо Currency. Я так тоже проверил - работает. Но, сдаётся мне, методика расчёта базы нарастающим итогом сложением после деления всё равно хромает. Сейчас исчезнет, а потом появится.

[vk65]

Можно банально на базу поставить тип real вместо Currency. Я так тоже проверил - работает.

Не уверен, что это полностью поможет - это ж только разрядность после запятой увеличит. Мне кажется, правильнее всё-таки округлять. Меня, к примеру, в excel раздражает, когда иногда получается, что 2 + 2 = 4,00000012

Но, сдаётся мне, методика расчёта базы нарастающим итогом сложением после деления всё равно хромает. Сейчас исчезнет, а потом появится.

Это-да. Если есть возможность заменить деление сложением, это нужно сделать обязательно.

[vk65]

а расписать для каждого тарифа максимальную сумму начисленных взносов в конкретном году и проверять её.

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

[semenova984]

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

В программу добавлен отчет, сверяющий данные по расчетным сумма ПФР и в пачек, а также он ищет превыщение уплаченных взносов перед начисленными аз весь период расчета (с 01.01.2010 по конец текущего квартала)

Кроме того, пришлось сделать загрузку из файлов XML, которые могут быть переданы пенсионным фондом страхователю

Уже было 5-6 случаев, когда мне пришлось синхронизировать данные с ПФР, так как они правили наши данные и распределяли уплату по-своему, а страхователя об этом не предупредили (я поднимал отдельную тему по этому поводу).

Так что в подобном случае действую следующим образом:

1. запрашиваю в ПФР пачки 1 и 2 полугодия 2010 года (а они не отказывают, ибо понимают, что погорячились с самостоятельным распределением)

2. удаляю из программы наши пачки и загружаю вариант ПФР

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

4. подаю отчет 1 квартала заново - проблема решена

А где это обсуждалось? Интересно почитать

[lubezniy]

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

[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 колонок, т.к. в настоящее время закреплённая область занимает более половины экрана, неудобно просматривать остальные данные.

[lubezniy]

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

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

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

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

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