Переход с устаревшей конфигурации 1С:Зарплата и кадры бюджетного учреждения, редакция 1.0 (ЗКБУ) на современную 1С:Зарплата и кадры государственного учреждения, редакция 3.1 (ЗКГУ) — процесс, вызывающий множество вопросов у программистов и расчетчиков. Ситуация осложняется тем, что фирма «1С» параллельно развивает несколько технологических веток программы, а сам процесс переноса данных таит в себе неочевидные методологические нюансы. В этой статье мы подробно разберем, какую стратегию перехода выбрать, на какую версию ориентироваться и как исправить типичные ошибки учета НДФЛ и налоговых вычетов, возникающие после переноса.
В период активного перехода пользователей на редакцию 3.1 фирма «1С» внедрила практику параллельного ведения нескольких веток одной и той же конфигурации. Давайте разберем, для чего это было сделано и с какими трудностями столкнулись пользователи:
1С:Предприятие 8.3.Критически важное ограничение: Многие пользователи планировали перейти на стабильную версию 3.1.5, однако столкнулись с тем, что «1С» заблокировала возможность загрузки данных из старых баз (ЗКБУ 1.0 / ЗУП 2.5) в линейку 3.1.5. Разработчики переписали механизмы переноса и оставили их поддержку только в актуальных ветках (начиная с 3.1.7 и 3.1.8). Таким образом, для осуществления первоначального перехода пользователям приходится разворачивать более новые, развивающиеся конфигурации (например, 3.1.8).
При этом пугаться перехода на промежуточные ветки не стоит. Как справедливо отмечают специалисты, переход со «старой» стабильной ветки на новую — это не повторный перенос данных с нуля, а обычное обновление конфигурации через стандартный запуск в режиме Конфигуратора, которое проходит в штатном режиме.
Очень частая проблема, с которой сталкиваются расчетчики сразу после переноса данных в новую базу ЗКГУ 3.1: при попытке сформировать отчет 2-НДФЛ за год перехода (например, 2018 год) в новой базе отображаются сведения только за один месяц — декабрь. Данные за предыдущие 11 месяцев года в отчет не попадают.
Давайте выясним причину этого поведения. Принятая методология перехода («рекомендованный» или краткий перенос данных на 1 января нового года) подразумевает перенос кадровой истории и расчетных данных, необходимых для исчисления среднего заработка, а также сальдо взаиморасчетов. Исторические расчетные данные по начисленной зарплате и НДФЛ за предыдущие месяцы (с января по ноябрь) в новую базу принципиально не переносятся.
В новую базу переносится только декабрьская зарплата как входящее сальдо (задолженность организации перед сотрудниками) и исчисленный НДФЛ за декабрь, поскольку их фактическая выплата и удержание налога будут происходить уже в новой программе в январе следующего года.
Решение: Пытаться собрать годовую отчетность по НДФЛ в новой базе после краткого переноса — это грубая методологическая ошибка. Согласно официальным рекомендациям фирмы «1С», сдавать регламентированную отчетность по формам 2-НДФЛ и 6-НДФЛ за год, предшествующий году начала эксплуатации новой программы, необходимо исключительно из старой информационной базы (ЗКБУ 1.0), где полноценно велся учет на протяжении всего налогового периода.
Другая распространенная техническая проблема при переносе данных на стыке годов: право на личные или имущественные налоговые вычеты переносится в новую базу с датой начала применения, соответствующей первому месяцу ведения учета в новой базе (например, январь 2019 года), вместо реальной даты начала применения (например, январь 2018 года). Из-за этого при расчете или корректировке декабрьской зарплаты в новой базе вычеты не применяются.
Проанализируем ситуацию. При фиксации кадровых и налоговых остатков на дату перехода документы Заявление на вычеты по НДФЛ автоматически создаются в новой базе с датой начала действия, соответствующей месяцу начала эксплуатации (январь 2019). Программа считает, что до этой даты учета в базе не существует.
Что делать в этой ситуации? Если расчетчику крайне необходимо пересчитать или скорректировать декабрь предыдущего года внутри новой базы (например, из-за сдвига выплаты зарплаты на январь или исправления ошибок ввода), необходимо выполнить следующие действия:
Заявление на вычеты по НДФЛ, созданный помощником переноса данных.Операция учета НДФЛ, чтобы вручную зафиксировать суммы предоставленных вычетов в регистре.Часто программисты и расчетчики сталкиваются с тем, что после корректировки вычетов и ручного перерасчета НДФЛ в документе Начисление зарплаты и взносов сумма исчисленного налога меняется в соответствии с ожиданиями, однако удержанный налог остается прежним (или вовсе пропадает из регистров).
Чтобы понять эту проблему, необходимо рассмотреть архитектуру учета НДФЛ в редакции 3.1. В отличие от старых версий (ЗКБУ 1.0 / ЗУП 2.5), где учет удержанного налога мог производиться «упрощенно» при проведении документов начисления, в ЗКГУ 3.1 исчисленный и удержанный НДФЛ — это два разных, жестко разделенных процесса, контролируемых независимыми регистрами накопления.
Начисление зарплаты и взносов.Ведомость в банк или Ведомость в кассу.Проведение перерасчета в начислении зарплаты корректирует только исчисленный налог. Чтобы изменился удержанный налог, необходимо в обязательном порядке перезаполнить или перепровести соответствующие платежные ведомости, которыми фактически выплачивалась эта заработная плата.
Для технического анализа расхождений между исчисленным и удержанным налогом программист может воспользоваться следующим запросом к регистру накопления РасчетыНалогоплательщиковСБюджетомПоНДФЛ:
ВЫБРАТЬ
НДФЛ.Сотрудник КАК Сотрудник,
СУММА(НДФЛ.Исчислено) КАК Исчислено,
СУММА(НДФЛ.Удержано) КАК Удержано
ИЗ
(ВЫБРАТЬ
Сотрудник,
Сумма КАК Исчислено,
0 КАК Удержано
ИЗ
РегистрНакопления.РасчетыНалогоплательщиковСБюджетомПоНДФЛ КАК Рег
ГДЕ
Рег.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
Сотрудник,
0,
Сумма
ИЗ
РегистрНакопления.РасчетыНалогоплательщиковСБюджетомПоНДФЛ КАК Рег
ГДЕ
Рег.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Расход)) КАК НДФЛ
СГРУППИРОВАТЬ ПО
НДФЛ.Сотрудник
ХАВИНГ
СУММА(НДФЛ.Исчислено) <> СУММА(НДФЛ.Удержано)
Этот несложный запрос поможет быстро выявить сотрудников, по которым образовался перекос между начислением и фактической выплатой, что особенно важно при выверке остатков после переноса данных.
Начиная с версии 3.1.8, разработчики «1С» кардинально изменили технический процесс переноса данных со старых конфигураций:
Out of memory.Тем не менее, первые релизы этого механизма содержали ошибки (некорректный перенос остатков отпусков, сбитые регистры учета времени). Поэтому при переносе данных настоятельно рекомендуется использовать самые актуальные релизы конфигураций обеих баз и тщательно сверять сформированные документы переноса данных.