Коэффициент уплаты и данные на начало периода

[yante]

это только тем у кого нет программиста по личной просьбе измученного бухгалтера

Вот это не проблема - любого бухгалтера мы запросто замучаем

[semenova984]

lubezniy, если я правильно понял, Вы хотите сконвертировать XLS файл таблицы в XML сведений для последующей загрузки в проги?
Если так, то это очень поможет тем кто пытается восстановить потерянные данные.

Согласна. Вот только бы определиться со структорой файда *.xls

[СергейI]

Вот это не проблема - любого бухгалтера мы запросто замучаем

так не пойдет, бухгалтер должен сам это сделать

[lubezniy]

Согласна. Вот только бы определиться со структорой файда *.xls

Я так понимаю, в ПТК СПУ или ещё каком-то комплексе есть готовая?

[semenova984]

Я так понимаю, в ПТК СПУ или ещё каком-то комплексе есть готовая?

Есть. Но вот лично я удаляю из неё лишние столбцы иногда, чтобы распечатать и всё красиво уместилось на одном листе

[vk65]

Я так понимаю, в ПТК СПУ или ещё каком-то комплексе есть готовая?

Рекомендую выяснить исходный формат, в котором происходит выгрузка.
У меня, например, есть ситуация (правда, из другой сферы), когда данные выгружаются в DBF, а при записи пользователям вручную пересохраняются в XLS.

[svv]

И страхователь может их сам легко получить, если есть на руках все файлы с 1 полугодия 2010.

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

Вот только дат увольнения в ней нет, а это печально.

По-моему в данном случае это не очень важно. Да и с датой увольнения обычно у бухгалтера нет вопросов.

Образец оригинального файла с измененными персональными данными постараюсь направить Вам на личную почту.

Может быть выложить на форум? Пользуются не только программами Бухсофта. Или у Бухсофта больше всего

измученного бухгалтера

[Валерий Ж]

один из отчетов из базы данных нарастающим итогом в целом по страхователю, (+)переплата, страховой номер без лидирующего "0", последний столбец, это последние начисления по ЗЛ, этот файл просто пример, но отражает схему формирования отчета, есть еще возможность формировать нарастающий итог до определенного периода, т.е. до 1 кв., до 2 кв. и т.д.,

[lubezniy]

один из отчетов из базы данных нарастающим итогом в целом по страхователю, (+)переплата, страховой номер без лидирующего "0", последний столбец, это последние начисления по ЗЛ, этот файл просто пример, но отражает схему формирования отчета, есть еще возможность формировать нарастающий итог до определенного периода, т.е. до 1 кв., до 2 кв. и т.д.,

Спасибо. В целом понятно. Можете для точного понимания дать ещё файлик на два периода? Хочу разобраться в структуре раскладывания данных по ячейкам в разных случаях.
Пока вывод такой. Для формирования XML данных, конечно, мало: если реквизиты организации можно вбить вручную, то стаж по каждому сотруднику будет в этой части сущим мучением. Думаю, есть ли смысл делать такие XML без стажа.

[svv]

Думаю, есть ли смысл делать такие XML без стажа.

Смотря для какой цели. Для ответа на вопрос "непогашенная задолженность по работнику по состоянию на..." - конечно есть.
Может есть другие цели?

[lubezniy]

Смотря для какой цели. Для ответа на вопрос "непогашенная задолженность по работнику по состоянию на..." - конечно есть.
Может есть другие цели?

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

[svv]

нужна для корректировки соответствующих данных в бух. программах

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

[lubezniy]

Если я правильно понимаю у нас 3 типа данных: стаж, начисленные взносы, уплаченные взносы.

В XML-файле - да. Ну и у обеих сторон тоже.

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

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

Ну т.е. на первый взгляд основная проблема рисуется именно с уплатой (отсутствие единых алгоритмов, ошибки в реализации алгоритма распределении уплаты и т.п.).

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

Если же мы хотим сравнить и прочие данные (стаж, начисления), то в эксель это удобоваримо не запихнуть, как на первый взгляд мне кажется (из-за сложных вариантов стажа). Особенно если вспомнить что один и тот же работник мог в организации одновременно проходить разными категориями.

А стаж не с чем сравнивать.

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

Нужен он или нет - вопрос не тот. Проблема в неясности поведения конкретной бухпрограммы конкретного страхователя в случае, если в неё импортировать файл без стажа. Если она очистит стаж по работникам, будет та ещё песня.

[yante]

один из отчетов из базы данных нарастающим итогом в целом по страхователю, (+)переплата, страховой номер без лидирующего "0", последний столбец, это последние начисления по ЗЛ, этот файл просто пример, но отражает схему формирования отчета, есть еще возможность формировать нарастающий итог до определенного периода, т.е. до 1 кв., до 2 кв. и т.д.,

У нас такое рассылают. Вот только бы они раскладывали бы эти суммы по Отчетным периодам, иначе не понятно, где они ошибку нашли...

[v_i_b]

Проблема в неясности поведения конкретной бухпрограммы конкретного страхователя в случае, если в неё импортировать файл без стажа. Если она очистит стаж по работникам, будет та ещё песня.

Проблема найти бухпрограмму (не набивалку для ИС), в которую можно импортировать данные СЗВ-6.