<?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='\
ПРФ рекомендует по уволенным закрывать суммы полностью.
Но, вот мнение 1С, озвученное на их форуме:
Таким образом, для уволенных сотрудников суммы начисленных и уплаченных страховых взносов не обязаны(!) совпадать. Совпадение будет только в том случае, когда взносы за июнь были перечислены в июне.
В следующем отчетном периоде (за полугодие) Вы подадите сведения об уплаченных суммах, в том числе и за уволенных.
Обращаем Ваше внимание, что если в сведениях текущего периода Вы измените распределение уплаченных сумм, то и в последующие периоды уплаченные суммы придется редактировать вручную.
Этот алгоритм войдет в релиз 2.5.26.
Так что, решайте сами, надо ли Вам сейчас использовать эту обработку и готовится к перераспределению уплаченных взносов в следующем периоде (если алгоритм все-таки будет реализован) или поверить обещаниям 1С и оставить пропорциональное распределение.
Какой-то косяк с уволенными. Если сотрудник был уволен, а потом опять принят, то попадает в уволенные.
(2) Я проверяю состояние работника не на текущий день, а на дату конца отчетного периода, т.е. в этом случае на 30.06.2010 (если уволен 30.06.2010, то считаю его уволенным, несмотря на то, что движения в регистре идут 01.07.2010). А если он принят позднее конца отчетного периода, то он попадает в уволенные.
При определении состояние, собираю всех сотрудников этого физлица на дату конца отчетного периода, сортирую в порядке убывания даты и смотрю первую запись, если это увольнение, то он считается уволенным.
Проверил в своей базе — все нормально. Если человека принят снова 30.06.2010, то он уходит в работающих, если 01.07.2010, то в уволенных. Если программа, работате так, как задумано, то это не косяк 😀 .
Посмотрел у тех, кто делал подобные обработки по 7.7: тоже определяют состояние работника на конец отчетного периода, а не на текущую дату. Каждый волен исправить отчет под себя, дерзайте.
Хотя… увольнение по внутр. совместительству я не предусмотрел — оно нас не интересует. Счас исправлю и выложу исправленную версию. Хорошо, что навели на мысль.
(1)1С всегда имеет мнение, которое оправдывает их действия в стиле «а нам так проще». После того как они объявили удержание за неотработанные дни отпуска удержанием с точки зрения НК, тем просто упростив себе жизнь, к их мнению прислушиваться страшновато.
Вот очередные примеры:
Это каким же образом, ПФР такие сведения, где уплата больше начисления не принимает?
А это почему? Мы уплатили за уволенного все, оставшиеся уплаты распределили между остальными. В след. полугодии та часть уплаты, которая приходилась на уволенного (та часть, которую мы ему как бы переплатили в 1- полугодии, если считать по КУ), распределится на всех остальных. Зачем что-то править руками? Если мы уплатим все во 2-м полугодии до конца года, то и распределенная за год сумма у нас будет равна начислениям за год. Непонятно что предполагается «редактировать вручную»?
Обработка супер.
Я программист и меня постоянно мои расчетчики терроризируют по этому поводу.
ПФР сами не знают как эту сумму рассчитывать. В программе «Документы ПУ» расчет идет тоже просто коэффициентом как в 1С, причем у нас сумма уплаченного во втором полугодии больше чем начислено. Эта программа и 1С просто обрезают и ставят как начислено. Есть еще программа «Оренбурга» она дает ставить коэффициент больше единицы, но опять же просто коэффициент не какого учета прошлого периода. Уже сам хотел писать что либо с учетом прошлого периода. А тут эта обработка. Сейчас вообще будут каждые 3 месяца сдавать. Так что все еще впереди.
Мои расчетчики говорят что если сотрудник уволен в декабре 2010, а уплата за него идет в январе 2011, то по нему никак не может быть сумма уплаченного равна сумме начисленного. Может стоит немного поправить алгоритм?
Мои расчетчики говорят что если сотрудник уволен в декабре 2010, а уплата за него идет в январе 2011, то по нему никак не может быть сумма уплаченного равна сумме начисленного. Может стоит немного поправить алгоритм?
Ну… это мнение Ваших расчетчиков, а наш ПФР считает, что в первую очередь мы с оплаты второго полугодия должны закрывать ВСЮ сумму по уволенным, работавших во втором полугодии, а то, что осталось, распределить пропорционально продолжающим работать. И именно так обработка распределяет взносы.
А Вашим расчетчика отлично подойдет стандартный механизм распределения уплат страховых взносов, реализованный в ЗУП 2.5. Нужно лишь правильно разнести уплату, в этом Вам может помочь публикация
А использовать обработку «Перераспределение страховых взносов» из этой публикации в Вашем случае нет нужды.
(7) В обработке есть косяк, если есть корректировка по сотрудника за прошлый период.
Т.е. в предыдущие пачки мы указываем исходную опись/пачку за 1 полугодие + корректирующую опись/пачку второго полугодия (но корректируемый период указан первым).
Нажимаем кнопку «Перераспределить оплату» и получаем в таблицах двойные записи по сотруднику, чьи взносы корректировали.
Например, в справочной таблице сотрудник идет два раза ( причем не рядом!) и его суммы (1 полугодие + корректировка) суммируются, что неверно. должна остаться только одна запись 🙁
Например, в 1 полугодии был остаток 505 рублей, после исправления должно быть 453, и итоговая сумма уплаты должна быть 453, а получаем сумму 958 рублей 🙁
Но общая сумма уплаты по всем сотрудникам рассчитывается все равно верно, т.к. распределение получается странное 🙁
Это не косяк, просто я НЕ предусматривал корректировки как таковые, т.к. наш ПФР корректировки не принимает вообще. Они заново просят сдавать ИСХОДНЫЕ.
(9) Предлагаю инфу из описания обработки на сайте закинуть в справочную информацию обработки.
Пользователям будет проще 🙂
СПАСИБО огромное!!!! обработка супер!
Спасибо, обработка замечательная,
возможно ли реализовать распределение уплаченных страховых взносов в ПФР не только по уволенным до декабря 2010г, но и по сотрудникам, доход которых до 12.2010г превысил 415 000,0 руб. То есть, в декабре начисления по ним не производились и остатков к уплате не должно быть.
Спасибо, обработка замечательная,
возможно ли реализовать распределение уплаченных страховых взносов в ПФР не только по уволенным до декабря 2010г, но и по сотрудникам, доход которых до 12.2010г превысил 415 000,0 руб. То есть, в декабре начисления по ним не производились и остатков к уплате не должно быть.
Да, мне уже говорили об этом, но ситуация хорошо отрабатывается только, если платят, как Вы пишете, т.е. не позднее след. месяца, а доход был закрыт не позднее декабря. Я подумаю, над этим, чтобы переносить их тоже в таблицу уволенных (и закрываемых в первую очередь под 100%). Реализовать это, конечно, возможно. Как найду время, сделаю.
Гениальная обработка! Огромное спасибо!!!
Да, мне уже говорили об этом, но ситуация хорошо отрабатывается только, если платят, как Вы пишете, т.е. не позднее след. месяца, а доход был закрыт не позднее декабря. Я подумаю, над этим, чтобы переносить их тоже в таблицу уволенных (и закрываемых в первую очередь под 100%). Реализовать это, конечно, возможно. Как найду время, сделаю.
Для своих клиентов доработал Вашу обработку, может кому еще пригодится, находится тут ( ) спасибо за идею 🙂
Большое спасибо, учитывая «полный цейтнот», обработка была очень кстати 🙂
А у нас что не так? Формируем на релизе 33.4. вылазят остатки прошлых периодов по многим людям, и много людей попадает в уволенные, работающих нет совсем в перераспределении. Сумма уплаты в верхнем окне совпадает с нашими цифрами, а итоговая сумма не совпадает, а именно она и идет потом в опись
(18) Не знаю, что не так…
У меня уже формировали в 2.5.33.4 за 1 квартал 2011. Но вот обнаружил неприятность: если в прошлом отчетном периоде уплата была больше начисления, то для корректного распределения приходится в качестве предыдущих периодов тянуть и 1-ое и 2-ое полугодие 2010 года. Что меня огорчило, ведь совсем не хотелось тянуть всю историю накоплением для остатков уплаты.
А лишние люди могут выскочить, т.к. 1С не учитывает, как были зафиксированы уплаты и всегда собирает список людей с остатками, которые уже могут быть закрыты. Т.е. это будут сотрудники без стажа, уплаты и начислений. В обработке их можно почистить.
Ну и, конечно, есть порядок работы в описании к обработке.
У нас уплата равна начислениям, пытались брать и первое полугодие 2010 года, тогда еще большая сумма садится в уплату по людям. Порядок работы конечно прочитали. В любом случае спасибо большое.
(20) Печально… но не могу со слов понять в чем проблема. У меня еще многие не сдавались, может что вспывет, подкорректирую код и опубликую исправленную версию обработки с дальнейшими рекомендациями.
(16) Я тоже доработал свою обработку.
Доделал там все, чего ей не хватало (и что дорабатывали другие):
1) использование КатегорииЗастрахованныхЛиц при определении суммы остатка к закрытию,
2) возможность распределить уплату превысившим предельную величину базы страховых взносов вместе с уволенными.
По уволенным в текущем периоде при формировании за 1 квартал косячокс.. Ибо попадают те кто уволены в апреле-мае…
В запросе по уволенным, стоит ДобавитьКДате(&ОтчетныйПЕриод,Квартал,2).. для 1 квартала нужно (&ОтчетныйПЕриод,Квартал,1)
(23)Спасибо за внимательность, исправил. Но не буду же писать запрос под каждый год свой…
Ввел новый параметр запроса
и соответственно
Молодец! То, что нужно!
Спасибо!!!!!!!!!!
Только пришлось чуть подшаманить))) Сумму уплаченных берет из пачек, а у нас переплата. Соответственно в пачках не указанна. Добавил возможность задавать ручками. Результат — полные штаны радости.
Спасибо, оч.помогли. Одна поправка, у меня была корректирующая 2010 г., для того чтобы правильно распределились суммы, нужно было её убрать из списка отчетов и оставить только правильную.
(27) Корректировки в прошлых периодах отрабатывает нормально, а вот что делать с текущими, не знаю. Мои бухи не хотят думать над алгоритмом, т.к. не пользуются ими (за 1,5 года в 100 организациях всего 1 корректировка).
Если не отменить проведение пачек, то можно потерять часть уплаченной суммы из-за неудавшейся попытки проведения одной из пачек.
В этом случае если опять с теми-же настройками перераспределить суммы (например, для проверки), то суммы уплаты изменятся.
Большое спасибо за обработку!
Попробовала эту обработку, но кое-что меня не устраивает. А именно:
1). Во 2-ю таблицу должны включаться уволенные в текущем году(в последнем месяце предыдущего квартала и в 1 и 2 месяце отчетного квартала) и у кого превышен предел для начисления взносов (так же: в последнем месяце предыдущего квартала и в 1 и 2 месяце отчетного квартала), а у меня ещё включаются по уволенным: работающие, но у кого закончился договор ГПХ в 2010 году, а в 2011 — снова заключен договор ГПХ с этим работником или работающие в 2011 — имеющие несколько договоров ГПХ с перерывами. По тем, у кого превышен предел — все включаются, но я бы тех, у кого предел превышен в последнем месяце отчетного периода, не включала в эту таблицу, т.к. взносы за последний месяц отчетного периода ещё не перечислены в отчетном периоде.
2). И самое главное, что не устраивает: не возможно тех, кого я указала в пункте 1). перенести (или добавить) в 3-ю таблицу «Работающие текущего периода» и чтобы потом всё правильно перераспределилось.
(29) naddy, в последней версии я сделал проведение всех пачек в единой транзакции, надеюсь это уменьшит количество проблем при записи (хотя в описании я все же рекомендовал работать с записанными, но не проведенными пачками).
(30) Для «030757»:
По договорникам ситуация описана неверно, я всегда договорников (которые не оформлены еще и как основные сотрудники) включаю в уволенных, независимо от того, на какой период оформлен договор.
Платят все по-разному, кто-то месяц в месяц, кто-то с опозданием на полгода (мои вообще им распределяют на общих основаниях).
Обработке уже год, никто такое не просил.
Невозможно создать обработку, которая бы устраивала всех подряд, если что-то не устраивает, то нужно исправить обработку под себя (хотя бы не надо писать ее с нуля). По крайней мере, я так и делаю, когда качаю разработки с инфостарта.
Кроме того, если обработка в корне не устраивает и нет возможности исправить под свои нужды (код открыт), то воспользуйтесь новым механизмом распределения взносов в ЗУП (тоже учитывает исправленные суммы прошлых периодов).
P.S. Очень уж много гнева для пользователя, который не выложил ни одной разработки.
BoneD, Вы не верно меня поняли (это я — 030757, теперь ButakovaTG). Никакого гнева от моего сообщения не исходило. Мне понравилась Ваша разработка, как пользователю (я бухгалтер и конечно никаких разработок у меня нет), но про некоторые нюансы, которые не устроили меня (как я считаю должны распределяться уплаченные взносы), я и написала, чтобы может быть Вы приняли их к сведению и может внесли какие-либо изменения.
А вот о договорниках, которые не оформлены еще и как основные сотрудники, можно поподробнее?
(32) Кадровые данные сотрудников подыскиваются в справочнике по физлицу. Если он был оформлен по трудовому договору, то я могу определить его периоды работы в организации, если же он всегда оформлялся только по договору подряда, в кадровых данных по нему ничего нет (в этом случае надо копаться в договорах подряда), поэтому я его причисляю к уволенным.
Так получилось, что у меня на предприятии почти все договорники — это, фактически, доплаты работникам, оформленным по трудовым договорам, а тех, кто оформлен только по договорам подряда мало и это реально разовые суммы, которые никто не будет рассматривать по дате окончания.
Накопительную по уволенным неправильно закрывает…
Не ошибка ли в строке 1125 модуля:
«СтрокаТаблицы.УплаченоНакопительная = Мин(НакопительнаяКУплате,Макс(УплаченоНакопительная-РаспределеноУплаченоНакопительная,0));»
Наверное, должно быть СтрокаТаблицы.НачисленоНакопительная
(34)
Не ошибка ли в строке 1125 модуля:
«СтрокаТаблицы.УплаченоНакопительная = Мин(НакопительнаяКУплате,Макс(УплаченоНакопительная-РаспределеноУплаченоНакопительная,0));»
Да… ошибка в модуле, тяжелый был день, спасибо за внимательность (ошибку поймали все, кто скачал обработку 10.08.2011 после 14:00 МСК). Исправил, обновил публикацию.
Так и должно быть
(27) Версия от 15.08.2011. Доработано: корректирующие пачки исключаются из отчетного периода (не мешаются при распределении уплат и не «кривят» начисление) и сразу учитываются в остатках вместо основных данных прошлых периодов.
Спасибо, обработкой пользовались, т.к. местный ПФР запросил, чтобы распределение уплат было именно таким. Клиент очень нервничал, у них более 600 человек, и много текучки, пионерский лагерь через каждые 5 недель, принимают и увольняют весь год. Воспользовались обработкой и сдали. Все довольны.
В своё время (при сдаче отчётности за 2010 год) обработка очень помогла. Правда сейчас типовые решения ЗУП выполняют практически тот же функционал, но автору огромное спасибо, поскольку был первым, кто сделал реально работающее решение проблемы. Использовалась на 10 организациях — везде ПФР принял отчёты без проблем
Автору спасибо!
очень незаменима если в базе много народу и за всеми не уследить, и очень полезна тем, что сделана внешней.
Аналогичный алгоритм разрабатывал для себя, выдвигал на форуме разработчиков предложения.
В данной разработке сделан не бесспорно, но прилично и полезно.
Но, как-то пропустил выход первой версии 🙂
При сдаче отчетности за 2010 год пользовались первоначальным вариантом обработки. Большое спасибо автору.
Огромное спасибо автору.
(44) softgarant, есть «правоборцы», которые долго и упорно бодаются ПФР, что те не правы, а меня просто попросили доработать алгоритм, чтобы легко и просто подавать сведения в ПФР (конкретно, филиал ПФР в г.Кирове).
Учет сумм прошлых документов есть, как минимум, в программах «Spu_orb» и «ПУ-5». Обе рекомендованы ПФР. Вообще не понимаю, по какому поводу паника???
ЗУП с релиза 2.5.40.3 поддерживает только распределение с учетом сумм прошлых документов, так что Ваше заявление не актуально!!! Учитывая этот факт, можно сказать, что отказаться от использоваться этой обработкой можно в любом отчетном периоде.
Я никого не принуждаю к использованию её. Выбор ВСЕГДА за конечным пользователем.
О том, что могут возникнуть проблемы при отказе от этой обработки в одном из последующих отчетных периодах я сам писал в (1), но тогда в ЗУП ещё не было расчета с учетом прошлых документов, был только пропорциональный расчет с кучей «тараканов», в котором мне не хотелось копаться.
Автору респект и уважуха!
да, очень полезная обработка, очень поможет при работе с ЗКП 2.5
СПАСИБО огромное !! я хочу сказать, что Ваша обработка спасла просто нас !!! и рекомендовали друзьям, все были просто счастливы.Хорошо , что есть такие люди, которые помогают не сильно «острым» (читай -тупым) товарищам :))
Замечательная штука. Очень нужная, я не побоюсь этого слова, каждому расчетчикубухгалтеру. Мне очень жаль, что реализовать такие расчеты в стандартной конфигурации 1С пока не захотело, Но радует что есть еще профессионалы-алтруисты. Спасибо Вам большое.
Спасибо, обработка очень хорошая, пригодилась в самый нужный момент.
(49) Это скорее не альтруизм, а взаимовыгодный обмен знаниями. Просто сам кое-что качал с Инфостарта, поэтому выкладываю взамен свои наработки. Правда, если руку к доработке публикаций не прикладывал, денег с клиента не беру, но и вопросы в счет разработки не принимаю.
К слову сказать, в 1С уже почти всё сделали из функционала моей обработки (через год), кроме очерёдности распределения взносов… тоже работают ребята.
не работает…такое ощущение что эта обработка для 8,1
(52) Нет, обработка точно под 8.2, попробуйте заново скачать, может браузер «сглючил».
Сам скачал файл с сайта, открыл, всё работает.
И что конкретно у Вас «не работает», какое сообщение выходит?
заработала))) спасибо))
Еще раз спасибо! Обработка порой является единственной соломинкой для спасения ситуации!
Добрый вечер! Автору большое спасибо за обработку! Но при попытке перераспределения сумм за 3 квартал, суммы уплаты остались не верными, т.е. в АДВ суммы уплаты меньше чем в документах «расчеты по страховым взносам». В чём может быть проблема. За ранее спасибо!
(56) Что надо проверить:
— проведены ли и проставлен признак «Принято в ПФР» в пачках АДВ прошлых периодов.
— внесены ли предыдущие АДВ в регистр сведений «СведенияПринятыеПФР».
Это повлияет на заполнение АДВ стандартной обработкой. И еще раз прошу перед пользованием обработки всё-таки почитать описание. Там есть такое замечание: «Если сумма уплаты не соответствует реальной оплаченной сумме (такое бывает, когда сумма оплаты в периоде больше суммы начисления или после перехода с ЗиК 7.7), то нужно добавить разницу к сумме уплаты любому сотруднику в любой пачке перед распределением, а лучше сотруднику с пустой уплатой (чтобы не ошибиться). После перераспределения сумма распределится в полном объеме, по описанному выше алгоритму.»
Обработка изначально не формирует суммы уплаты по людям на основании оплат (и не заменяет её собой полностью), а лишь перераспределяет сформированные типовой обработкой сумм между сотрудниками по несколько иному алгоритму.
Спасибо за ответ! Буду пробовать.
Очень хотелось бы видеть или порекомендовать автору, брать суммы уплаченных взносов не из самих пачек СЗВ, а из документов где отражаются расчеты с ПФР, или регистров по этим документам.
Уточняю свой вопрос, что суммы оплаченно по страховой части и накопительной части, можно ли брать из документов «Расчеты по страховым взносам» или из их регистров. Ведь очень актально распределять сумму именно с этих документов, так как если брать непосредственно с пачек, не всегда верно, вполне возможно результат «Уплачено» в этих пачках был сформировн самой программой 1С уже не верно. Приходится вручную по некоторым людям добавлять разницу по уплате некую сумму по любому человеку и заново распределять по всем. Есле такая возможность будет реализовано, будет вполне законченное решение. А вообще автору за обработку огромное спасибо. В свое время это была единственное решение для распределение сумм в 2010 и полугодие 2011 гг.
Очень пригодилась обработка. Удивительно, почему разработчики 1С не могут сделать сразу всё красиво. Стандартная обработка считает очень криво, а ваша всё это дело красиво исправляет. Большое спасибо за обработку!
(60) Сделал оба варианта определения суммы уплаты. Старый (через настройку) и новый, как просили из документов «Расчеты по страховым взносам»(по-умолчанию). В версии 2.5.40.3 действительно стало больше ошибок с распределением суммы уплаты типовым механизмом.
Не могу скачать данную обработку. Очень нужно.. Скиньте на мыло altress@yandex.ru
Мне тоже пожалуйста скиньте кто может на мыло alex_atc@mail.ru
Обработка отличная, очень помогла, рекомендую! Проходилась обработкой по пачкам за полугодие, все красиво сделала, все уволенные закрылись, бухгалтер в восторге. Спасибо Вам огромное, жаль не могу скачать доработанную версию обработки, из-за недостаточного количества баллов на сайте))) Если не сложно скиньте пожалуйста на мыло stmyp@mail.ru, буду очень благодарна.
Очень хочу скачать эту обработку, перепробовал уже все различные.. никак не хотят принимать сведения.. не могу скачать обработку, из-за недостаточного количества баллов на сайте))) если кому не сложно скиньте пожалуйста на мыло nikdn@inbox.ru, заранее благодарен!!
Большое спасибо за данную обработку, очень помогла.. и еще огромное спасибо Ивану, приславшему её на мыло)))
(67) nikdn, будьте так добры, пришли мне, пожалуйста. stmyp@mail.ru
Буду очень благодарен, кого не затруднит пришлите пожалуйста на мыло leks_is@list.ru
Эта проблема с 1 копейкой — просто невыносимая головная боль.
Надеюсь, я найду в этой обработке решение.
Спасибо огромное за обработку, очень нужная и очень помогла, отдельное спасибо nikdn, приславшему обработку
Большое спасибо за обработку!!! Очень помогла.
Отличная и очень нужная вещь!
спасибо
большое
Здорово,отличная вещь, да еще и бесплатно
Добрый день!!!
Воспользовался Вашей обработкой, но выдает непонятные результаты:
пример. У нас Задолженность по страховой части 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 то обработки видит все нормально и распределение идет идеально.
(75) festiv1, если есть остатки, то я закрываю их в первую очередь, не важно чьи они, уволенных или не уволенных.
Ещё хотелось бы точно (до копеек) знать сумму уплаты, а то по описанию похоже, что они немного меньше остатков, т.к. при уплате больше начисления, я просто закрываю суммы, а если меньше (хоть на копейку), то начинаю пропорциональное закрытие остатков. Тут уж без округления никак, вот и сливается разница на одного их сотрудников. Ну и скрин бы неплохо (общие суммы и итоги по таблицам), а то не всё понятно, сотрудников можно «замазать». Вот примерно как у меня… Там, как раз, схожая ситуация.
Вот скрин.
Спасибо за ответ. Да действительно остаток страхования больше суммы уплаты, но почему идет разница между уплачено страховая и итог по таблице Оплаченные остатки прошлого периода уплачено страховая разнятся (обведено черным). и эта разница добавляется первому уволенному (обведено красным)
(77) да… странная какая-то ситуация, там есть минусовые остатки? Можно ли приложить все 3 таблицы (без 2-х колонок «Сведения…» и «Физлицо», колонки «N» и «Учтен» оставить) и сообщения, которые выходят при распределении? Попробую еще в таблицах покопаться, может что найду.
(78)
Минусовые остатки есть. Вот 3 таблицы и сообщения при распределении
(79) ситуация прояснилась, — если убрать все неучтённые строки в таблицах (сотрудники с остатками, которых нет в пачках отчётного периода), то получаем сумму учтённого для уплаты остатка 7801081,95 (больше, т.к. многие неучтённые с переплатами, а мы ожидали 7801075,11). Получается коэфф. уплаты остатков 0,99999880785767158874673788037825.
Я проверил около 10 строк — всё посчиталось верно, согласно этого коэффициента. С учетом округления получилось, что не всё распределилось по остаткам, эта сумма и была отнесена на первого уволенного, чтобы полностью распределить уплату.
Таблица остатков справочная, она просто показывает какие остатки были закрыты при уплате, реальная сумма уплаты = итоги уплаты по уволенным и работающим 7801072,65.
В случае нехватки уплаты даже на остатки, я остатки распределяю пропорционально (если хватает, то полностью).
С учетом вышесказанного, такое поведение обработки считаю полностью соответствующим заложенному алгоритму.
Проблема изначально возникает из-за большого кол-во переплат по физлицам, чего не должно быть (ни в теории, ни на практике). У нас все такие пачки прошлых периодов были возвращены из ПФР на переделку и сданы заново (даже из-за 1 копейки).
Спасибо большое за разъяснения… А вот у нас не возвращали пачки и теперь придется мучатся…
(81) Недолго мучаться придётся, ещё вернут. У нас недавно стали возвращать за 2010 год (возвраты были по «принятым» периодам). Подавали по некоторым организациям за 2-3 отчетных периода данные заново.
Какой бы ни был инструмент, бухг. всё-равно умудряются «накосячить» (лучше бы спросили лишний раз).
Нам все равно придется мучаться… Мы на ЗУП перешли только 3 месяца назад… до этого были в ЗИК 7.7 все косяки от туда и пошли
При нажатии кнопки «Перераспределить взносы» выдается сообщение :Сотрудника ЧИСТЯКОВА Н.П. (НАЕМ/РАБОТНИК) нет в текущем документе. Суммы ОСТАТКОВ (20167,77(стр.) и 0,00(нак.)) не учтены при распределении оплаты.И так несколько человек, все они уволены, не подскажете, что с ними делать?
(84) k, в описании публикации (и в тексте справки к обработке) есть такие слова: «Если какой-то сотрудник (которому должен быть распределен остаток оплаты за прошлый период) не попал в пачки автоматически, его надо добавить в нужную пачку перед распределением.»
Спасибо за обработку, жаль поздно о ней узнала, не понятно почему 1с-ники не реализуют в программе такой механизм распределения взносов, долг по уволенным тащится из квартала в квартал?
Спасибо большое автору за обработку! Пользуемся второй год, работает как часы. Каждый раз вспоминаю добрым словом хорошего человека :))
Большое спасибо за публикацию. Очень помогло. Спасибо за труд.
Спасибо за обработку, очень помогла в распределениии, особенно по уволенным
Жаль, что поздно увидела эту обработку….воспользуюсь в будущем….Спасибо….особенно по уволенным пригодится….
у меня ничего не перераспределяется, оставляет все как есть
(91) kuzmina_ann, поздравляю с почином. Вы первые такие.
А если серьёзно, то всё надо сделать по инструкции, которая есть в публикации и в справке к обработке. Ни разу не видел, чтобы обработка распределила точно так же, как было в типовом распределении (т.е. ничего не изменила).
Хотя нет… такое возможно в том случае, если в отчетном периоде ничего не уплатили. Но тогда незачем использовать обработку, там и так всем в уплате «0» будет.
вы на последнем релизе пробовали?
(93) kuzmina_ann, в последнем релизе 2.5.42.4 поменяли структуру некоторых регистров, и модули переписали (как обычно), возможно из-за этого что-то перестало работать. Сегодня начал готовить обновление, соотв. в течение недели всё буду смотреть.
На релизе 2.5.41.3 не было проблем.
Более ничего сказать не могу.
Прошу обратить внимание на Дердюк Иван Михайлович, он уволен 01.11.2010 и даже добавила его в первоочередников, не могу понять в чем дело, помогите и так по всем уволенным. Все делаю по инструкции и на релизе 2.5.42.3 пробовала — везде одно и тоже
(95) kuzmina_ann, Здесь всё нормально а именно: сумма задолженности за прошлые отчётные периоды превышает сумму уплаты в текущем отчётном периоде, значит закрывается пропорционально только сумма остатков, а суммы начислений текущего периода не закрываются. Суммы, находящиеся в сальдо, могут относится как к работающим, так и уволенным ранее или в отчётном периоде.
Последние начисления по Дердюк были в январе 2011 года, последняя сумма уплаты за 1 квартал прошла июлем 2011, т.е Дердюк должен закрыться в отчете за 9 месяцев!!! То есть те люди, у которых последние начисления были только в первом квартале должны закрыться полностью, так как уплата за 1 квартал 2011 года была произведена полностью!!! В чем смысл Вашей обработки? У нас уплата в текущем периоде всегда меньше задолженности за прошлые периоды, тогда получается, что такие люди (уволенные) у нас не закроются никогда???
(97) Когда должен был закрыться дердюк я не знаю, я говорю только о том, что вижу на форме. А по тем данным, что указаны (текущая пачка и ВСЕ предыдущие с начала 2010 года), получается, что у него есть ещё задолженность по уплате страховой 505.52.
Получается, что да, а как Вы хотели, чуда не будет. Если закрывать под 0 по алфавиту, то будет ещё хуже: первые по алфавиту будут всегда закрываться под 0, а последние остануться вообще без оплаты. Такой вариант кажется более предпочтительным, наверное нет???
Как ни крути, но если уплата меньше, чем долг, а при этом ещё ведь есть начисления текущего периода, то долг неизбежно будет нарастать, это математика, с ней не поспоришь!
Тут только 1 вариант. Закрывать среди долгов в первую очередь уволенных, но лично мне этот вариант пока не нужен, т.к. у меня платят довольно исправно.
Вот именно этот вариант нам и нужен!!!