Переход на новые версии программных продуктов 1С часто сопровождается сложностями, особенно когда часть инфраструктуры остается на старых платформах. Одной из наиболее острых проблем является организация обмена данными между современной «1С:Зарплата и управление персоналом 3.1» (ЗУП) и проверенной временем «1С:Бухгалтерия предприятия 2.0» (БП). Рассмотрим, почему стандартные средства здесь бессильны и как решить технические проблемы переноса данных.
Разберем ситуацию: фирма «1С» официально прекратила поддержку прямого обмена через механизм «Синхронизация данных» для связки ЗУП 3.1 и БП 2.0. Современная ЗУП ориентирована на работу с БП версии 3.0. Поэтому для переноса данных нам придется использовать классический инструмент — «Конвертация данных 2.0» и обработку Универсальный обмен данными в формате XML.
Основная сложность, с которой сталкиваются разработчики, заключается в том, что структура документа ОтражениеЗарплатыВБухучете в ЗУП 3.1 кардинально отличается от структуры аналогичного документа в БП 2.0. Выясним причины, по которым вкладки «Начисленный НДФЛ» и «Удержанная зарплата» часто остаются пустыми при загрузке.
Проанализируем ситуацию подробнее. В ЗУП 3.1 данные по НДФЛ в документе отражения детализированы по сотрудникам и документам-основаниям. В БП 2.0 структура этого документа более упрощенная. Если в правилах конвертации объектов (ПКО) не прописан четкий алгоритм сопоставления (маппинг), данные просто не находят своего места.
Основные причины ошибок:
СпособыОтраженияЗарплатыВБухучете в ЗУП 3.1 не синхронизирован по наименованию с БП 2.0, счета учета в загруженном документе будут пустыми.Рассмотрим, как правильно настроить правила, чтобы заполнить проблемные вкладки. Нам необходимо убедиться, что для табличных частей документа ОтражениеЗарплатыВБухучете прописаны соответствующие правила конвертации свойств (ПКС).
Для переноса НДФЛ важно в обработчике ПослеЗагрузки или непосредственно в правилах сопоставления объектов указать алгоритм поиска сотрудников. Поиск должен идти по связке ИНН + СНИЛС или по ФИО. Если поиск не сработает, вы получите пустые ссылки в документе.
Посмотрим на пример логики, которую можно реализовать в правилах для сопоставления счетов:
// Пример логики в ПКС для СчетаДт или СчетаКт
Если ОбъектИсточник.ВидОперации = Перечисления.ВидыОперацийНачисленияЗарплаты.Удержание Тогда
Значение = ПланыСчетов.Хозрасчетный.НайтиПоКоду("76.41");
КонецЕсли;
Выясним причину, почему проводки не формируются даже при наличии данных в документе. В ЗУП 3.1 справочник СпособыОтраженияЗарплатыВБухучете содержит только наименования. Вся «магия» счетов Дт/Кт и аналитики (субконто) хранится в аналогичном справочнике в БП 2.0.
Важное правило: наименования способов отражения в обеих базах должны совпадать до символа, включая регистр и пробелы. Рассмотрим последовательность действий:
При загрузке правила конвертации найдут способ отражения по наименованию и автоматически подтянут нужные счета из бухгалтерии.
Если настройка правил конвертации XML кажется слишком трудоемкой, можно воспользоваться подходом, упомянутым в практике внедрений — созданием собственной обработки загрузки. Разберем этот метод.
Вместо использования Универсального обмена, мы можем написать обработку для БП 2.0, которая будет считывать данные напрямую из файла (например, Excel или JSON), выгруженного из ЗУП 3.1. Это позволяет «на лету» сопоставлять колонки и программно заполнять объект ДокументОбъект.ОтражениеЗарплатыВБухучете.
Пример программного заполнения табличной части НДФЛ в БП 2.0:
НоваяСтрока = ДокументОбъект.НДФЛ.Добавить();
НоваяСтрока.ФизЛицо = Справочники.ФизическиеЛица.НайтиПоРеквизиту("ИНН", ДанныеИзЗУП.ИНН);
НоваяСтрока.Налог = ДанныеИзЗУП.СуммаНДФЛ;
НоваяСтрока.ПодразделениеОрганизации = Справочники.ПодразделенияОрганизаций.НайтиПоНаименованию(ДанныеИзЗУП.Подразделение);
Проанализируем еще один нюанс: страховые взносы. В ЗУП 3.1 они детализированы до каждого работника. В зависимости от учетной политики в БП 2.0, данные могут требовать сворачивания (агрегации). Если ваши правила конвертации просто копируют строки, документ в БП 2.0 может стать слишком громоздким, что приведет к ошибкам при проведении.
Что касается резервов отпусков (оценочных обязательств), то их перенос требует отдельных правил. В ЗУП 3.1 используется сложный механизм расчета, который часто не совпадает с логикой БП 2.0. Мы рекомендуем переносить остатки по резервам отдельной операцией или дорабатывать правила так, чтобы они создавали в бухгалтерии документ ОценочныеОбязательства.
Чтобы ваш обмен работал стабильно, придерживайтесь следующих советов:
Таким образом, даже при отсутствии штатного механизма, связка ЗУП 3.1 и БП 2.0 вполне работоспособна при правильной настройке правил конвертации или использовании внешних инструментов загрузки данных.