Перераспределение уплаты страховых взносов для ЗУП 2.5 в пачках СЗВ-6 (+ проверка переплаты и отчёты по периодам) до 2014 года




Принцип обмена данными из 1С с сайтом (на MySQL) и выдачи (публикации) этих данных по запросу.
PHP-Скрипт автоматической загрузки данных из файла данных в формате CSV в базу данных сайта работающего на WordPress.

В продолжение моей темы: 1С:Альфа-Авто Автосалон Автосервис: обмен с сайтом.
С помощью данного скрипта можно загружать в автоматическом режиме, по расписанию, данные сервисных книжек (ремонтов авто) из 1С:Альфа-Авто Автосалон Автосервис.
Также можно загружать данные в ручном режиме: для этого делается скрытая страница, где размещается специальная кнопка.
Комментарии размещенные внутри скрипта разъяснят логику и порядок действия.
Комментарии с "/////    echo" использовались для отладки.
Дополнительно создана таблица для журналирования результатов загрузки данных.
Скрипт включает в себя защиту от SQL инъекций (думаю безопасность соблюдена в полной мере).
В кратце:
1. Пишется скрипт, который запускает этот.
2. Создается регламентное задание в WordPress, по которому запускается скрипт из п.1. 
3. Этот скрипт осуществляет проверку на существование файла обмена в папке.
4. Если данные не новые, загрузка не производится.
5. Если данные новые, очищается таблица сервисных книжек.
6. Загружаются новые данные.

Собственно сам скрипт:

<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55

global $wpdb2;
global $failure;
global $file_hist;

/////  echo '<H2><b>Старт загрузки</b></H2><br>';

$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
/////   echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}

$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
/////   echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}

/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
/////   echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
/////    echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist);   ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7];    ////получаем размер файла
$m_mtime_file=$masiv_data_file[9];   ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file

/////   echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
/////   echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
/////   echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);

if ($results)
{   foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));

////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
/////   echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
/////   echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}

////загружаем данные
$table='vin_history';         // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация     // (путь от корня web-сервера)
$delim=';';          // Разделитель полей в CSV файле
$enclosed='"';      // Кавычки для содержимого полей
$escaped='\

99 Comments

  1. BoneD

    ПРФ рекомендует по уволенным закрывать суммы полностью.

    Но, вот мнение 1С, озвученное на их форуме:

    Алгоритм пропорционального распределения уплаченных сумм предложен ПФРом (и даже опубликован в «памятках страхователю»). Этот алгоритм основывается на Постановлении Правительства РФ от 12.06.2002 № 407, которое предусматривает в том числе «дописывание» сумм в расчетный капитал при поступлении оплаты за прошлые периоды.

    Таким образом, для уволенных сотрудников суммы начисленных и уплаченных страховых взносов не обязаны(!) совпадать. Совпадение будет только в том случае, когда взносы за июнь были перечислены в июне.

    В следующем отчетном периоде (за полугодие) Вы подадите сведения об уплаченных суммах, в том числе и за уволенных.

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

    Мы делаем такой алгоритм, чтобы при уплате за прошлый период в качестве базы распределения использовались бы начисленные за прошлые периоды суммы взносов, т.е. те же самые суммы, которые использовались при составлении отчетности за соответствующий прошлый период. Таким образом, как только уплаченные суммы за какой-то период совпадут с начисленными, так сразу же в отчетность попадут все «остатки» уплат и по физлицам суммы «закроются».

    Этот алгоритм войдет в релиз 2.5.26.

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

    Reply
  2. Armando

    Какой-то косяк с уволенными. Если сотрудник был уволен, а потом опять принят, то попадает в уволенные.

    Reply
  3. BoneD

    (2) Я проверяю состояние работника не на текущий день, а на дату конца отчетного периода, т.е. в этом случае на 30.06.2010 (если уволен 30.06.2010, то считаю его уволенным, несмотря на то, что движения в регистре идут 01.07.2010). А если он принят позднее конца отчетного периода, то он попадает в уволенные.

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

    Проверил в своей базе — все нормально. Если человека принят снова 30.06.2010, то он уходит в работающих, если 01.07.2010, то в уволенных. Если программа, работате так, как задумано, то это не косяк 😀 .

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

    Хотя… увольнение по внутр. совместительству я не предусмотрел — оно нас не интересует. Счас исправлю и выложу исправленную версию. Хорошо, что навели на мысль.

    Reply
  4. Pin

    (1)1С всегда имеет мнение, которое оправдывает их действия в стиле «а нам так проще». После того как они объявили удержание за неотработанные дни отпуска удержанием с точки зрения НК, тем просто упростив себе жизнь, к их мнению прислушиваться страшновато.

    Вот очередные примеры:

    В следующем отчетном периоде (за полугодие) Вы подадите сведения об уплаченных суммах, в том числе и за уволенных.

    Это каким же образом, ПФР такие сведения, где уплата больше начисления не принимает?

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

    А это почему? Мы уплатили за уволенного все, оставшиеся уплаты распределили между остальными. В след. полугодии та часть уплаты, которая приходилась на уволенного (та часть, которую мы ему как бы переплатили в 1- полугодии, если считать по КУ), распределится на всех остальных. Зачем что-то править руками? Если мы уплатим все во 2-м полугодии до конца года, то и распределенная за год сумма у нас будет равна начислениям за год. Непонятно что предполагается «редактировать вручную»?

    Reply
  5. OlegDy

    Обработка супер.

    Я программист и меня постоянно мои расчетчики терроризируют по этому поводу.

    ПФР сами не знают как эту сумму рассчитывать. В программе «Документы ПУ» расчет идет тоже просто коэффициентом как в 1С, причем у нас сумма уплаченного во втором полугодии больше чем начислено. Эта программа и 1С просто обрезают и ставят как начислено. Есть еще программа «Оренбурга» она дает ставить коэффициент больше единицы, но опять же просто коэффициент не какого учета прошлого периода. Уже сам хотел писать что либо с учетом прошлого периода. А тут эта обработка. Сейчас вообще будут каждые 3 месяца сдавать. Так что все еще впереди.

    Reply
  6. ashein

    Мои расчетчики говорят что если сотрудник уволен в декабре 2010, а уплата за него идет в январе 2011, то по нему никак не может быть сумма уплаченного равна сумме начисленного. Может стоит немного поправить алгоритм?

    Reply
  7. BoneD
    ashein пишет:

    Мои расчетчики говорят что если сотрудник уволен в декабре 2010, а уплата за него идет в январе 2011, то по нему никак не может быть сумма уплаченного равна сумме начисленного. Может стоит немного поправить алгоритм?

    Ну… это мнение Ваших расчетчиков, а наш ПФР считает, что в первую очередь мы с оплаты второго полугодия должны закрывать ВСЮ сумму по уволенным, работавших во втором полугодии, а то, что осталось, распределить пропорционально продолжающим работать. И именно так обработка распределяет взносы.

    А Вашим расчетчика отлично подойдет стандартный механизм распределения уплат страховых взносов, реализованный в ЗУП 2.5. Нужно лишь правильно разнести уплату, в этом Вам может помочь публикация Проверка сумм уплаты страховых взносов для отчета в ПФР (ЗУП, БП, КА, УПП)

    А использовать обработку «Перераспределение страховых взносов» из этой публикации в Вашем случае нет нужды.

    Reply
  8. artbear

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

    Т.е. в предыдущие пачки мы указываем исходную опись/пачку за 1 полугодие + корректирующую опись/пачку второго полугодия (но корректируемый период указан первым).

    Нажимаем кнопку «Перераспределить оплату» и получаем в таблицах двойные записи по сотруднику, чьи взносы корректировали.

    Например, в справочной таблице сотрудник идет два раза ( причем не рядом!) и его суммы (1 полугодие + корректировка) суммируются, что неверно. должна остаться только одна запись 🙁

    Например, в 1 полугодии был остаток 505 рублей, после исправления должно быть 453, и итоговая сумма уплаты должна быть 453, а получаем сумму 958 рублей 🙁

    Но общая сумма уплаты по всем сотрудникам рассчитывается все равно верно, т.к. распределение получается странное 🙁

    Reply
  9. BoneD

    Это не косяк, просто я НЕ предусматривал корректировки как таковые, т.к. наш ПФР корректировки не принимает вообще. Они заново просят сдавать ИСХОДНЫЕ.

    Reply
  10. artbear
    Reply
  11. artbear

    (9) Предлагаю инфу из описания обработки на сайте закинуть в справочную информацию обработки.

    Пользователям будет проще 🙂

    Reply
  12. never_desponding

    СПАСИБО огромное!!!! обработка супер!

    Reply
  13. DO_WHILE_LOOP

    Спасибо, обработка замечательная,

    возможно ли реализовать распределение уплаченных страховых взносов в ПФР не только по уволенным до декабря 2010г, но и по сотрудникам, доход которых до 12.2010г превысил 415 000,0 руб. То есть, в декабре начисления по ним не производились и остатков к уплате не должно быть.

    Reply
  14. BoneD
    DO_WHILE_LOOP пишет:

    Спасибо, обработка замечательная,

    возможно ли реализовать распределение уплаченных страховых взносов в ПФР не только по уволенным до декабря 2010г, но и по сотрудникам, доход которых до 12.2010г превысил 415 000,0 руб. То есть, в декабре начисления по ним не производились и остатков к уплате не должно быть.

    Да, мне уже говорили об этом, но ситуация хорошо отрабатывается только, если платят, как Вы пишете, т.е. не позднее след. месяца, а доход был закрыт не позднее декабря. Я подумаю, над этим, чтобы переносить их тоже в таблицу уволенных (и закрываемых в первую очередь под 100%). Реализовать это, конечно, возможно. Как найду время, сделаю.

    Reply
  15. LaninaNata

    Гениальная обработка! Огромное спасибо!!!

    Reply
  16. DO_WHILE_LOOP
    BoneD пишет:

    Да, мне уже говорили об этом, но ситуация хорошо отрабатывается только, если платят, как Вы пишете, т.е. не позднее след. месяца, а доход был закрыт не позднее декабря. Я подумаю, над этим, чтобы переносить их тоже в таблицу уволенных (и закрываемых в первую очередь под 100%). Реализовать это, конечно, возможно. Как найду время, сделаю.

    Для своих клиентов доработал Вашу обработку, может кому еще пригодится, находится тут ( http://infostart.ru/public/81183/ ) спасибо за идею 🙂

    Reply
  17. nks

    Большое спасибо, учитывая «полный цейтнот», обработка была очень кстати 🙂

    Reply
  18. ГердаКай

    А у нас что не так? Формируем на релизе 33.4. вылазят остатки прошлых периодов по многим людям, и много людей попадает в уволенные, работающих нет совсем в перераспределении. Сумма уплаты в верхнем окне совпадает с нашими цифрами, а итоговая сумма не совпадает, а именно она и идет потом в опись

    Reply
  19. BoneD

    (18) Не знаю, что не так…

    У меня уже формировали в 2.5.33.4 за 1 квартал 2011. Но вот обнаружил неприятность: если в прошлом отчетном периоде уплата была больше начисления, то для корректного распределения приходится в качестве предыдущих периодов тянуть и 1-ое и 2-ое полугодие 2010 года. Что меня огорчило, ведь совсем не хотелось тянуть всю историю накоплением для остатков уплаты.

    А лишние люди могут выскочить, т.к. 1С не учитывает, как были зафиксированы уплаты и всегда собирает список людей с остатками, которые уже могут быть закрыты. Т.е. это будут сотрудники без стажа, уплаты и начислений. В обработке их можно почистить.

    Ну и, конечно, есть порядок работы в описании к обработке.

    Reply
  20. ГердаКай

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

    Reply
  21. BoneD

    (20) Печально… но не могу со слов понять в чем проблема. У меня еще многие не сдавались, может что вспывет, подкорректирую код и опубликую исправленную версию обработки с дальнейшими рекомендациями.

    Reply
  22. BoneD

    (16) Я тоже доработал свою обработку.

    Доделал там все, чего ей не хватало (и что дорабатывали другие):

    1) использование КатегорииЗастрахованныхЛиц при определении суммы остатка к закрытию,

    2) возможность распределить уплату превысившим предельную величину базы страховых взносов вместе с уволенными.

    Reply
  23. softpanorama

    По уволенным в текущем периоде при формировании за 1 квартал косячокс.. Ибо попадают те кто уволены в апреле-мае…

    В запросе по уволенным, стоит ДобавитьКДате(&ОтчетныйПЕриод,Квартал,2).. для 1 квартала нужно (&ОтчетныйПЕриод,Квартал,1)

    Reply
  24. BoneD

    (23)Спасибо за внимательность, исправил. Но не буду же писать запрос под каждый год свой…

    Ввел новый параметр запроса

    Запрос.УстановитьПараметр(«ОтчетныйПериодОкончание»,ПроцедурыПерсонифицированногоУчета.ОкончаниеОтчетногоПериодаПерсучета(ПередачаСЗВ4вПФРСсылка.ОтчетныйПериод)+1);

    и соответственно

    | РегистрСведений.РаботникиОрганизаций.СрезПоследних(&ОтчетныйПериодОкончание, Организация = &Организация) КАК РаботникиОрганизацийСрезПоследних
    Reply
  25. Diversus

    Молодец! То, что нужно!

    Reply
  26. Ateterev

    Спасибо!!!!!!!!!!

    Только пришлось чуть подшаманить))) Сумму уплаченных берет из пачек, а у нас переплата. Соответственно в пачках не указанна. Добавил возможность задавать ручками. Результат — полные штаны радости.

    Reply
  27. Hilda Fildgerald

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

    Reply
  28. BoneD

    (27) Корректировки в прошлых периодах отрабатывает нормально, а вот что делать с текущими, не знаю. Мои бухи не хотят думать над алгоритмом, т.к. не пользуются ими (за 1,5 года в 100 организациях всего 1 корректировка).

    Reply
  29. naddy

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

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

    Большое спасибо за обработку!

    Reply
  30. ButakovaTG

    Попробовала эту обработку, но кое-что меня не устраивает. А именно:

    1). Во 2-ю таблицу должны включаться уволенные в текущем году(в последнем месяце предыдущего квартала и в 1 и 2 месяце отчетного квартала) и у кого превышен предел для начисления взносов (так же: в последнем месяце предыдущего квартала и в 1 и 2 месяце отчетного квартала), а у меня ещё включаются по уволенным: работающие, но у кого закончился договор ГПХ в 2010 году, а в 2011 — снова заключен договор ГПХ с этим работником или работающие в 2011 — имеющие несколько договоров ГПХ с перерывами. По тем, у кого превышен предел — все включаются, но я бы тех, у кого предел превышен в последнем месяце отчетного периода, не включала в эту таблицу, т.к. взносы за последний месяц отчетного периода ещё не перечислены в отчетном периоде.

    2). И самое главное, что не устраивает: не возможно тех, кого я указала в пункте 1). перенести (или добавить) в 3-ю таблицу «Работающие текущего периода» и чтобы потом всё правильно перераспределилось.

    Reply
  31. BoneD

    (29) naddy, в последней версии я сделал проведение всех пачек в единой транзакции, надеюсь это уменьшит количество проблем при записи (хотя в описании я все же рекомендовал работать с записанными, но не проведенными пачками).

    (30) Для «030757»:

    а у меня ещё включаются по уволенным: работающие, но у кого закончился договор ГПХ в 2010 году, а в 2011 — снова заключен договор ГПХ с этим работником или работающие в 2011 — имеющие несколько договоров ГПХ с перерывами

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

    По тем, у кого превышен предел — все включаются, но я бы тех, у кого предел превышен в последнем месяце отчетного периода, не включала в эту таблицу, т.к. взносы за последний месяц отчетного периода ещё не перечислены в отчетном периоде.

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

    И самое главное, что не устраивает: не возможно тех, кого я указала в пункте 1). перенести (или добавить) в 3-ю таблицу «Работающие текущего периода» и чтобы потом всё правильно перераспределилось.

    Обработке уже год, никто такое не просил.

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

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

    P.S. Очень уж много гнева для пользователя, который не выложил ни одной разработки.

    Reply
  32. ButakovaTG
    Очень уж много гнева для пользователя, который не выложил ни одной разработки.

    BoneD, Вы не верно меня поняли (это я — 030757, теперь ButakovaTG). Никакого гнева от моего сообщения не исходило. Мне понравилась Ваша разработка, как пользователю (я бухгалтер и конечно никаких разработок у меня нет), но про некоторые нюансы, которые не устроили меня (как я считаю должны распределяться уплаченные взносы), я и написала, чтобы может быть Вы приняли их к сведению и может внесли какие-либо изменения.

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

    А вот о договорниках, которые не оформлены еще и как основные сотрудники, можно поподробнее?

    Reply
  33. BoneD

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

    Так получилось, что у меня на предприятии почти все договорники — это, фактически, доплаты работникам, оформленным по трудовым договорам, а тех, кто оформлен только по договорам подряда мало и это реально разовые суммы, которые никто не будет рассматривать по дате окончания.

    Reply
  34. Julietta

    Накопительную по уволенным неправильно закрывает…

    Не ошибка ли в строке 1125 модуля:

    «СтрокаТаблицы.УплаченоНакопительная = Мин(НакопительнаяКУплате,Макс(УплаченоНакопительная-РаспределеноУплаченоНакопительная,0));»

    Наверное, должно быть СтрокаТаблицы.НачисленоНакопительная

    Reply
  35. BoneD

    (34)

    Накопительную по уволенным неправильно закрывает…

    Не ошибка ли в строке 1125 модуля:

    «СтрокаТаблицы.УплаченоНакопительная = Мин(НакопительнаяКУплате,Макс(УплаченоНакопительная-РаспределеноУплаченоНакопительная,0));»

    Да… ошибка в модуле, тяжелый был день, спасибо за внимательность (ошибку поймали все, кто скачал обработку 10.08.2011 после 14:00 МСК). Исправил, обновил публикацию.

    Наверное, должно быть СтрокаТаблицы.НачисленоНакопительная

    Так и должно быть

    Reply
  36. BoneD

    (27) Версия от 15.08.2011. Доработано: корректирующие пачки исключаются из отчетного периода (не мешаются при распределении уплат и не «кривят» начисление) и сразу учитываются в остатках вместо основных данных прошлых периодов.

    Reply
  37. yanat

    Спасибо, обработкой пользовались, т.к. местный ПФР запросил, чтобы распределение уплат было именно таким. Клиент очень нервничал, у них более 600 человек, и много текучки, пионерский лагерь через каждые 5 недель, принимают и увольняют весь год. Воспользовались обработкой и сдали. Все довольны.

    Reply
  38. Ted1982

    В своё время (при сдаче отчётности за 2010 год) обработка очень помогла. Правда сейчас типовые решения ЗУП выполняют практически тот же функционал, но автору огромное спасибо, поскольку был первым, кто сделал реально работающее решение проблемы. Использовалась на 10 организациях — везде ПФР принял отчёты без проблем

    Reply
  39. gutentag

    Автору спасибо!

    Reply
  40. cerg110

    очень незаменима если в базе много народу и за всеми не уследить, и очень полезна тем, что сделана внешней.

    Reply
  41. СергейКа

    Аналогичный алгоритм разрабатывал для себя, выдвигал на форуме разработчиков предложения.

    В данной разработке сделан не бесспорно, но прилично и полезно.

    Но, как-то пропустил выход первой версии 🙂

    Reply
  42. isb

    При сдаче отчетности за 2010 год пользовались первоначальным вариантом обработки. Большое спасибо автору.

    Reply
  43. smok1986

    Огромное спасибо автору.

    Reply
  44. BoneD

    (44) softgarant, есть «правоборцы», которые долго и упорно бодаются ПФР, что те не правы, а меня просто попросили доработать алгоритм, чтобы легко и просто подавать сведения в ПФР (конкретно, филиал ПФР в г.Кирове).

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

    Учет сумм прошлых документов есть, как минимум, в программах «Spu_orb» и «ПУ-5». Обе рекомендованы ПФР. Вообще не понимаю, по какому поводу паника???

    ЗУП с релиза 2.5.40.3 поддерживает только распределение с учетом сумм прошлых документов, так что Ваше заявление не актуально!!! Учитывая этот факт, можно сказать, что отказаться от использоваться этой обработкой можно в любом отчетном периоде.

    Я никого не принуждаю к использованию её. Выбор ВСЕГДА за конечным пользователем.

    О том, что могут возникнуть проблемы при отказе от этой обработки в одном из последующих отчетных периодах я сам писал в (1), но тогда в ЗУП ещё не было расчета с учетом прошлых документов, был только пропорциональный расчет с кучей «тараканов», в котором мне не хотелось копаться.

    Reply
  45. sergey_zverev

    Автору респект и уважуха!

    Reply
  46. mihas1001

    да, очень полезная обработка, очень поможет при работе с ЗКП 2.5

    Reply
  47. lmichelle

    СПАСИБО огромное !! я хочу сказать, что Ваша обработка спасла просто нас !!! и рекомендовали друзьям, все были просто счастливы.Хорошо , что есть такие люди, которые помогают не сильно «острым» (читай -тупым) товарищам :))

    Reply
  48. bahbah

    Замечательная штука. Очень нужная, я не побоюсь этого слова, каждому расчетчикубухгалтеру. Мне очень жаль, что реализовать такие расчеты в стандартной конфигурации 1С пока не захотело, Но радует что есть еще профессионалы-алтруисты. Спасибо Вам большое.

    Reply
  49. maralex

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

    Reply
  50. BoneD

    (49) Это скорее не альтруизм, а взаимовыгодный обмен знаниями. Просто сам кое-что качал с Инфостарта, поэтому выкладываю взамен свои наработки. Правда, если руку к доработке публикаций не прикладывал, денег с клиента не беру, но и вопросы в счет разработки не принимаю.

    К слову сказать, в 1С уже почти всё сделали из функционала моей обработки (через год), кроме очерёдности распределения взносов… тоже работают ребята.

    Reply
  51. exlusi

    не работает…такое ощущение что эта обработка для 8,1

    Reply
  52. BoneD

    (52) Нет, обработка точно под 8.2, попробуйте заново скачать, может браузер «сглючил».

    Сам скачал файл с сайта, открыл, всё работает.

    И что конкретно у Вас «не работает», какое сообщение выходит?

    Reply
  53. exlusi

    заработала))) спасибо))

    Reply
  54. kubarik

    Еще раз спасибо! Обработка порой является единственной соломинкой для спасения ситуации!

    Reply
  55. Vital88

    Добрый вечер! Автору большое спасибо за обработку! Но при попытке перераспределения сумм за 3 квартал, суммы уплаты остались не верными, т.е. в АДВ суммы уплаты меньше чем в документах «расчеты по страховым взносам». В чём может быть проблема. За ранее спасибо!

    Reply
  56. BoneD

    (56) Что надо проверить:

    — проведены ли и проставлен признак «Принято в ПФР» в пачках АДВ прошлых периодов.

    — внесены ли предыдущие АДВ в регистр сведений «СведенияПринятыеПФР».

    Это повлияет на заполнение АДВ стандартной обработкой. И еще раз прошу перед пользованием обработки всё-таки почитать описание. Там есть такое замечание: «Если сумма уплаты не соответствует реальной оплаченной сумме (такое бывает, когда сумма оплаты в периоде больше суммы начисления или после перехода с ЗиК 7.7), то нужно добавить разницу к сумме уплаты любому сотруднику в любой пачке перед распределением, а лучше сотруднику с пустой уплатой (чтобы не ошибиться). После перераспределения сумма распределится в полном объеме, по описанному выше алгоритму.»

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

    Reply
  57. Vital88

    Спасибо за ответ! Буду пробовать.

    Reply
  58. Natge2008

    Очень хотелось бы видеть или порекомендовать автору, брать суммы уплаченных взносов не из самих пачек СЗВ, а из документов где отражаются расчеты с ПФР, или регистров по этим документам.

    Reply
  59. Natge2008

    Уточняю свой вопрос, что суммы оплаченно по страховой части и накопительной части, можно ли брать из документов «Расчеты по страховым взносам» или из их регистров. Ведь очень актально распределять сумму именно с этих документов, так как если брать непосредственно с пачек, не всегда верно, вполне возможно результат «Уплачено» в этих пачках был сформировн самой программой 1С уже не верно. Приходится вручную по некоторым людям добавлять разницу по уплате некую сумму по любому человеку и заново распределять по всем. Есле такая возможность будет реализовано, будет вполне законченное решение. А вообще автору за обработку огромное спасибо. В свое время это была единственное решение для распределение сумм в 2010 и полугодие 2011 гг.

    Reply
  60. guzelia

    Очень пригодилась обработка. Удивительно, почему разработчики 1С не могут сделать сразу всё красиво. Стандартная обработка считает очень криво, а ваша всё это дело красиво исправляет. Большое спасибо за обработку!

    Reply
  61. BoneD

    (60) Сделал оба варианта определения суммы уплаты. Старый (через настройку) и новый, как просили из документов «Расчеты по страховым взносам»(по-умолчанию). В версии 2.5.40.3 действительно стало больше ошибок с распределением суммы уплаты типовым механизмом.

    Reply
  62. festiv1

    Не могу скачать данную обработку. Очень нужно.. Скиньте на мыло altress@yandex.ru

    Reply
  63. DNS2010

    Мне тоже пожалуйста скиньте кто может на мыло alex_atc@mail.ru

    Reply
  64. ~Ponk@~

    Обработка отличная, очень помогла, рекомендую! Проходилась обработкой по пачкам за полугодие, все красиво сделала, все уволенные закрылись, бухгалтер в восторге. Спасибо Вам огромное, жаль не могу скачать доработанную версию обработки, из-за недостаточного количества баллов на сайте))) Если не сложно скиньте пожалуйста на мыло stmyp@mail.ru, буду очень благодарна.

    Reply
  65. nikdn

    Очень хочу скачать эту обработку, перепробовал уже все различные.. никак не хотят принимать сведения.. не могу скачать обработку, из-за недостаточного количества баллов на сайте))) если кому не сложно скиньте пожалуйста на мыло nikdn@inbox.ru, заранее благодарен!!

    Reply
  66. nikdn

    Большое спасибо за данную обработку, очень помогла.. и еще огромное спасибо Ивану, приславшему её на мыло)))

    Reply
  67. ~Ponk@~

    (67) nikdn, будьте так добры, пришли мне, пожалуйста. stmyp@mail.ru

    Reply
  68. trumanl

    Буду очень благодарен, кого не затруднит пришлите пожалуйста на мыло leks_is@list.ru

    Эта проблема с 1 копейкой — просто невыносимая головная боль.

    Надеюсь, я найду в этой обработке решение.

    Reply
  69. ~Ponk@~

    Спасибо огромное за обработку, очень нужная и очень помогла, отдельное спасибо nikdn, приславшему обработку

    Reply
  70. festiv1

    Большое спасибо за обработку!!! Очень помогла.

    Reply
  71. nealaran

    Отличная и очень нужная вещь!

    Reply
  72. dyh

    спасибо

    большое

    Reply
  73. Масянька

    Здорово,отличная вещь, да еще и бесплатно

    Reply
  74. festiv1

    Добрый день!!!

    Воспользовался Вашей обработкой, но выдает непонятные результаты:

    пример. У нас Задолженность по страховой части 7801072,65 за предыдущий период, мы ее выплатили в этом периоде. В пачках из программы распределение произошло всей суммы, в описи АДВ сумма 7801073, правда уволенные не закрылись, идет разница в несколько копеек, у некоторых до 6 копеек в зависимости о величины суммы. Воспользовался Вашей обработкой. В 1ой таблице (Оплаченные остатки прошлого периода) сумма уплаченно страховых 7801069,52, разница в 3.13 руб. Далее сравнил с суммами в пачках распределенными в 1с, разница у некоторых людей от 1 до 3 копеек. Например в 1с сумма уплаты 35769,18, в Вашей обработке в таблице Оплаченные остатки прошлого периода сумма 35769,15. Но на этом еще не все. Обработка распределяет всю сумму 7801072,65, но совсем непонятно как, некоторым записывает сумму на несколько копеек меньше как в предыдущем примере, а первому уволенному добавляет сумму в 3.13. Пример

    Акимов Алексей Николаевич остаток страхования 10241,94 уплачено страховая 10241,93 а в таблице Уволенные текущего периода уплачено страховая 10245,06.

    Если я в уплату добавляю 3.13 и распределяю в пачках в 1с становится уплата 7801075,78 то обработки видит все нормально и распределение идет идеально.

    Reply
  75. BoneD

    (75) festiv1, если есть остатки, то я закрываю их в первую очередь, не важно чьи они, уволенных или не уволенных.

    Ещё хотелось бы точно (до копеек) знать сумму уплаты, а то по описанию похоже, что они немного меньше остатков, т.к. при уплате больше начисления, я просто закрываю суммы, а если меньше (хоть на копейку), то начинаю пропорциональное закрытие остатков. Тут уж без округления никак, вот и сливается разница на одного их сотрудников. Ну и скрин бы неплохо (общие суммы и итоги по таблицам), а то не всё понятно, сотрудников можно «замазать». Вот примерно как у меня… Там, как раз, схожая ситуация.

    Reply
  76. festiv1

    Вот скрин.

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

    Reply
  77. BoneD

    (77) да… странная какая-то ситуация, там есть минусовые остатки? Можно ли приложить все 3 таблицы (без 2-х колонок «Сведения…» и «Физлицо», колонки «N» и «Учтен» оставить) и сообщения, которые выходят при распределении? Попробую еще в таблицах покопаться, может что найду.

    Reply
  78. festiv1

    (78)

    Минусовые остатки есть. Вот 3 таблицы и сообщения при распределении

    Reply
  79. BoneD

    (79) ситуация прояснилась, — если убрать все неучтённые строки в таблицах (сотрудники с остатками, которых нет в пачках отчётного периода), то получаем сумму учтённого для уплаты остатка 7801081,95 (больше, т.к. многие неучтённые с переплатами, а мы ожидали 7801075,11). Получается коэфф. уплаты остатков 0,99999880785767158874673788037825.

    Я проверил около 10 строк — всё посчиталось верно, согласно этого коэффициента. С учетом округления получилось, что не всё распределилось по остаткам, эта сумма и была отнесена на первого уволенного, чтобы полностью распределить уплату.

    Таблица остатков справочная, она просто показывает какие остатки были закрыты при уплате, реальная сумма уплаты = итоги уплаты по уволенным и работающим 7801072,65.

    В случае нехватки уплаты даже на остатки, я остатки распределяю пропорционально (если хватает, то полностью).

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

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

    Reply
  80. festiv1

    Спасибо большое за разъяснения… А вот у нас не возвращали пачки и теперь придется мучатся…

    Reply
  81. BoneD

    (81) Недолго мучаться придётся, ещё вернут. У нас недавно стали возвращать за 2010 год (возвраты были по «принятым» периодам). Подавали по некоторым организациям за 2-3 отчетных периода данные заново.

    Какой бы ни был инструмент, бухг. всё-равно умудряются «накосячить» (лучше бы спросили лишний раз).

    Reply
  82. festiv1

    Нам все равно придется мучаться… Мы на ЗУП перешли только 3 месяца назад… до этого были в ЗИК 7.7 все косяки от туда и пошли

    Reply
  83. k

    При нажатии кнопки «Перераспределить взносы» выдается сообщение :Сотрудника ЧИСТЯКОВА Н.П. (НАЕМ/РАБОТНИК) нет в текущем документе. Суммы ОСТАТКОВ (20167,77(стр.) и 0,00(нак.)) не учтены при распределении оплаты.И так несколько человек, все они уволены, не подскажете, что с ними делать?

    Reply
  84. BoneD

    (84) k, в описании публикации (и в тексте справки к обработке) есть такие слова: «Если какой-то сотрудник (которому должен быть распределен остаток оплаты за прошлый период) не попал в пачки автоматически, его надо добавить в нужную пачку перед распределением.»

    Reply
  85. Lena444

    Спасибо за обработку, жаль поздно о ней узнала, не понятно почему 1с-ники не реализуют в программе такой механизм распределения взносов, долг по уволенным тащится из квартала в квартал?

    Reply
  86. inake

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

    Reply
  87. sidorkina

    Большое спасибо за публикацию. Очень помогло. Спасибо за труд.

    Reply
  88. ГердаКай

    Спасибо за обработку, очень помогла в распределениии, особенно по уволенным

    Reply
  89. Len75

    Жаль, что поздно увидела эту обработку….воспользуюсь в будущем….Спасибо….особенно по уволенным пригодится….

    Reply
  90. kuzmina_ann

    у меня ничего не перераспределяется, оставляет все как есть

    Reply
  91. BoneD

    (91) kuzmina_ann, поздравляю с почином. Вы первые такие.

    А если серьёзно, то всё надо сделать по инструкции, которая есть в публикации и в справке к обработке. Ни разу не видел, чтобы обработка распределила точно так же, как было в типовом распределении (т.е. ничего не изменила).

    Хотя нет… такое возможно в том случае, если в отчетном периоде ничего не уплатили. Но тогда незачем использовать обработку, там и так всем в уплате «0» будет.

    Reply
  92. kuzmina_ann

    вы на последнем релизе пробовали?

    Reply
  93. BoneD

    (93) kuzmina_ann, в последнем релизе 2.5.42.4 поменяли структуру некоторых регистров, и модули переписали (как обычно), возможно из-за этого что-то перестало работать. Сегодня начал готовить обновление, соотв. в течение недели всё буду смотреть.

    На релизе 2.5.41.3 не было проблем.

    Более ничего сказать не могу.

    Reply
  94. kuzmina_ann

    Прошу обратить внимание на Дердюк Иван Михайлович, он уволен 01.11.2010 и даже добавила его в первоочередников, не могу понять в чем дело, помогите и так по всем уволенным. Все делаю по инструкции и на релизе 2.5.42.3 пробовала — везде одно и тоже

    Reply
  95. BoneD

    (95) kuzmina_ann, Здесь всё нормально а именно: сумма задолженности за прошлые отчётные периоды превышает сумму уплаты в текущем отчётном периоде, значит закрывается пропорционально только сумма остатков, а суммы начислений текущего периода не закрываются. Суммы, находящиеся в сальдо, могут относится как к работающим, так и уволенным ранее или в отчётном периоде.

    Reply
  96. kuzmina_ann

    Последние начисления по Дердюк были в январе 2011 года, последняя сумма уплаты за 1 квартал прошла июлем 2011, т.е Дердюк должен закрыться в отчете за 9 месяцев!!! То есть те люди, у которых последние начисления были только в первом квартале должны закрыться полностью, так как уплата за 1 квартал 2011 года была произведена полностью!!! В чем смысл Вашей обработки? У нас уплата в текущем периоде всегда меньше задолженности за прошлые периоды, тогда получается, что такие люди (уволенные) у нас не закроются никогда???

    Reply
  97. BoneD

    (97) Когда должен был закрыться дердюк я не знаю, я говорю только о том, что вижу на форме. А по тем данным, что указаны (текущая пачка и ВСЕ предыдущие с начала 2010 года), получается, что у него есть ещё задолженность по уплате страховой 505.52.

    У нас уплата в текущем периоде всегда меньше задолженности за прошлые периоды, тогда получается, что такие люди (уволенные) у нас не закроются никогда???

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

    Как ни крути, но если уплата меньше, чем долг, а при этом ещё ведь есть начисления текущего периода, то долг неизбежно будет нарастать, это математика, с ней не поспоришь!

    Тут только 1 вариант. Закрывать среди долгов в первую очередь уволенных, но лично мне этот вариант пока не нужен, т.к. у меня платят довольно исправно.

    Reply
  98. kuzmina_ann

    Вот именно этот вариант нам и нужен!!!

    Reply
  99. mtk
    Reply

Leave a Comment

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