К сожалению, на 335 релизе та же картина. А руками править неинтересно как-то, особенно с учетом численности под тыщу человек... Может делаем что не так, куда можно глянуть еще?
К сожалению, на 335 релизе та же картина. А руками править неинтересно как-то, особенно с учетом численности под тыщу человек... Может делаем что не так, куда можно глянуть еще?
судя по ветке - Вы не одиноки в проблеме. выход - править обработку или ждать обновление.
Ещё 2 вопроса:<br>1) Загрузили ли вы ранее переданные файлы в ПФР?<br>2) Выгружаются ли файлы текущего отчетного периода?
Ясно. Или все же людей руками разгребать ) Спасибо, будем ждать )
1) Ранее переданных в программе не увидела. Уточню завтра. Но скорее всего нет, потому что по крайней мере окончательную доводку бухгалтер делает не в 1С.<br>2) Файлы выгружаются.
Причину нашли, исправить не можем. Оказывается бухгалтер руками заносит сведения о стаже в справочник, бо ее не устраивает, как машина по договорам раскидывает стажи. Пример - договор вообще-то с 09.01.13 по 31.03.13, начисления идут в феврале, марте. Не знаю почему, наверное так надо, но она по каждому месяцу заносит новый договор (она объясняла, что это связано с тем, что часто договора на оплату приносят позже, чем они были заключены, и оплачивает она их позже). Словом проблема такая теперь: когда мы правим данные о стаже, выбираем вид догвора ГПХ вместо Трудовой, машина его якобы сохраняет, но когда закрываем-снова заходим - стоит опять вид договора Трудовой. И никак не найду, где в коде можно поправить этот момент... Может и н в коде, может как-то можно по-другому проблему обойти?
Может что подскажете...<br>Причину нашли, исправить не можем. Оказывается бухгалтер руками заносит сведения о стаже в справочник, бо ее не устраивает, как машина по договорам раскидывает стажи. Пример - договор вообще-то с 09.01.13 по 31.03.13, начисления идут в феврале, марте. Не знаю почему, наверное так надо, но она по каждому месяцу заносит новый договор (она объясняла, что это связано с тем, что часто договора на оплату приносят позже, чем они были заключены, и оплачивает она их позже). Словом проблема такая теперь: когда мы правим данные о стаже, выбираем вид догвора ГПХ вместо Трудовой, машина его якобы сохраняет, но когда закрываем-снова заходим - стоит опять вид договора Трудовой. И никак не найду, где в коде можно поправить этот момент... Может и н в коде, может как-то можно по-другому проблему обойти?
Стаж почему-то не сохраняется с видом договора ГПХ ( То есть его выбираем, сохраняет вроде бы. Выхоим-заходим - снова вид договора стоит Трудовой. А срок договора (реального) не совпадает со сроками, которые в договорах, по которым начисляется зарплата. Бухгалтер (она сказала, что ей так надо) каждый месяц заводит новый договор с человеком на месяц, и получается, что реальный срок работы например с 09.01 по 31.03, а машина видит по документам начисления 2 периода, как договора заносились - с 01.02 по 28.02 и с 01.03 по 31.03, что никого не устраивает...<br>Как это разрулить, не подскажете?
По справочникам ничем Вам не помогу. Я удалось победить только 2 эпизода:<br>1 чтобы договорники ГПХ не попадали в пачку Трудовых со своей задолженностью<br>2 чтобы файл сведений выгружался, если переданные в ПРФ пачки занесены в базу.<br>Есть ещё косяк - кнопки "Заполнить" и "Заполнить суммы" по-разному обрабатывают исчисленние взносы.<br>А вот с ручными исправлениями ни одноцй базы нет.<br>Немного непонятно, почему бух. не желает ставить реальные периоды договорам. Выплата всегда станет в периоде регистрации. НДФЛ тоже можно настроить, чтобы брал по месяцу выплаты, а стаж запишется сразу правильный.
"> Отдельная история с человеком, который работал с 1 по 16 января в штате, затем ушел на ГПХ. Он верно попадает в обе пачки, цифры все видит какие надо где надо, но в обоих случаях пишет стаж двумя строками - с 1 по 16 января и с 17 января по 31 марта.<br> <br>Похоже, что это ошибка в алгоритме и она есть во всех конфигурациях 7.7, актуальных на 17.04.2013 г.<br> <br>В отчете ПодготовкаСведенийДляПФР2010 Все конструкции вида:<br> <br><pre>Если ТаблицаСтажаСотрудника.НайтиЗначение(КатегорияЗЛ, НомСтрокиТССт, "КатегорияЗЛ")=0 Тогда </pre><br><br> <br>надо менять на<br> <br><pre>Ключ = глПолучитьКлючКатегорияЗЛТипДоговора(КатегорияЗЛ,ТипДоговора);<br>Если ТаблицаСтажаСотрудника.НайтиЗначение(Ключ, НомСтрокиТССт, "Ключ")=0 Тогда </pre><br><br>И посмотреть что для ТипДоговора где то выше по алгоритму присваивается значение, иногда это написано, иногда нет. Этот "ТипДоговора" добавили как колонку в таблицу стажей даже для старых лет для совместимости и во многих местах переделали алгоритм поиска по таблице с поиска по значению на поиск по ключу, но не везде. В частности в процедуре ПечатьСведений() точно есть эта ошибка и поэтому для договорника, имеющегося в пачке договорников и в пачке сотрудников стаж печатается дважды один и тот же и там и там. Хотя в процедуре ФайлСведенийСЗВ64() такой ошибки нет и все сделано корректно в этом месте.<br> <br>Кроме того, в глСобратьДанныеДляСЗВ2013() есть странный ход:<br>Описываются две таблицы значений: ВремТаблицаСтажаСотрудника и ВремТаблицаСтажаСотрудникаГПХ, но вторая нигде и никак не заполняется, она участвует в алгоритме только в момент описания ее структуры и далее в момент обработки сведений в ней находящихся, но сведния нигде в нее не заносятся, поэтому в данный момент вы в печатных формах видите хоть что то по стажу договорников из за наличия другой ошибки, описанной выше. Идет некорректный поиск, поэтому данные хоть какие то, но находятся, хотя и не принадлежат типу договора = ГПХ.<br> <br>Смотреть надо в глобальном модуле все места в процедуре, где есть<br>глВписатьОсновнуюЗаписьОСтаже2010(...,ВремТаблицаСоСтажем...)<br>Нужно определять где сведения надо вписывать в самом деле в ВремТаблицаСоСтажем, а где в ВремТаблицаСоСтажемГПХ, тогда они и в ТаблицаСтажаСотрудника корректно соберутся. Я сделал только для УСН 7.7, для остальных пока не разбирал.<br> <br>По вопросу о ненормальном поведении обработки ручного фиксирования сведений о стаже.<br>У моих было так: ввели данные о стаже 2013, они зафиксировались по ключу: ОтчетныйПериод+Сотрудник + КатегорияЗЛ<br>Я обновил конфигурацию и в справочник СЗВСтаж2010 добавился новый реквизит ТипДоговора.<br>Соответственно, ключ позиционирования сведений стал другим: ОтчетныйПериод+Сотрудник + КатегорияЗЛ+ТипДоговора<br>Но данные были в программу занесены ранее и реквизит ТипДоговора остался пустым, поэтому когда пользователь заходит в форму ввода сведений о стаже сотрудника, он не видит данные ни по категории "Трудовой", ни по категории "ГПХ". Но когда подготавливает пачки, они туда попадают с значением ТипДоговора = <пустое значение>. В обработке ОбновлениеИБ для ЗиК я вижу что есть преобразование элементов справочника СЗВСтаж2010 с установкой значения "Трудовой" в этот добавляемый реквизит, а в УСН это сделать, похоже, забыли. Поэтому на уровне пользователя сложно догадаться откуда глюк. На вашем месте я бы все равно проконтролировал уникальность и заполненность данных по ключам. Самое простое сделать так:<br>1. В конфигураторе ищем справочник СЗВСтаж2010<br>2. Открываем форму списка этого справочника<br>3. В модуле формы списка видим ругалку о том что справочник является системным и его значения исправлять нельзя. Закомментирим временно эти строки (поставим в их начале //):<br> <br><pre>//Предупреждение("Это системный справочник - его нельзя открыть в обычном режиме");<br>//СтатусВозврата(0); </pre><br><br> <br>4. Сохраняемся, идем в обычный режим работы с программой.<br>5. Открываем справочник сотрудников, на нужном сотруднике жмем правой кнопкой мышки и выбираем "Подчиненный справочник", указываем что нас интересует "СЗВ: сведения о стаже с 2010 г".<br>6. Смотрим заполнены ли для отчетных периодов 2013 года значения реквизита ТипДоговора. Если нет, то аккуратно проставляем их напрямую в справочнике.<br>7. Смотрим нет ли дублирования элементов со сведениями. Если такое есть, то вполне можно получить ситуацию когда вы в форме станете исправлять данные, а они станут сохраняться в элементы-клоны, поэтому вы и видите эффект "несохранения".<br>8. Идеальный вариант: по отчетному периоду 2013 года все элементы в этом справочнике метим на удаление. Проводим процедуру удаления элементов, помеченных на удаление и пользователь начисто вносит данные обычным образом через стандартную форму ввода. Данный способ разумен если ситуаций немного. Попробуйте на одном сотруднике.<br>9. Не забудьте в конфигураторе вернуть в исходное состояние строки, которые запрещают работать напрямую со справочником СЗВСтаж2010, а то там пользователь такого навводить может, потом не разобрать будет."
1C:Лекторий: 23 мая 2024 года — Бесплатная онлайн-лекция об учете финансовой аренды у арендодателя в программах 1С:ERP и 1С:КА 1C:Лекторий: 6 июня 2024 года — Бесплатная онлайн-лекция об отражении расчетов на ЕНС в «1С:Бухгалтерии 8» |
1C:Лекторий: 11 июня 2024 года — Бесплатная онлайн-лекция об учете работников-иностранцев на примере программы 1С:ЗУП ред.3 1C:Лекторий: 27 июня 2024 года — Бесплатная онлайн-лекция об учете доходов и расходов по национальным проектам на практических примерах в 1С:БГУ. Серия 1С:Консалтинг для госсектора |