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