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