Перенос документов вместе с их движениями (бухгалтерскими проводками, записями регистров накопления и расчета) — одна из классических задач в сфере интеграции систем 1С. Очень часто при настройке обмена через ПланОбмена или с использованием обработки УниверсальныйОбменДаннымиXML возникает вопрос: переносятся ли движения документов автоматически «один в один» из базы-источника, или же документ переносится пустым, а затем проводится в базе-приемнике заново?
В этой статье мы подробно разберем, как устроена механика работы с движениями при обмене данными, выясним причины ограничений автоматического создания правил в «Конвертации данных 2.1» (КД 2.0) и рассмотрим практические способы решения этой задачи.
При использовании КД 2.0 разработчики часто прибегают к функции автоматического создания правил. Однако при этом правила конвертации объектов (ПКО) создаются только для ссылочных типов (справочники, документы, задачи и т.д.). Регистры накопления, бухгалтерии и расчета не являются ссылочными объектами платформы — это наборы записей. Автоматический генератор правил КД 2.0 просто не умеет сопоставлять их без участия разработчика.
Для того чтобы движения документов корректно переносились, нам необходимо выполнить настройку вручную. Разберем этот процесс по шагам:
MD83Exp.epf обязательно убедитесь, что у вас снят флаг «Не выгружать движения документов». Если этот флаг будет установлен, информация о регистрах просто не попадет в файл метаданных, и вы не сможете настроить правила в КД 2.0.Даже если мы правильно настроили ПКС для регистров и движения выгрузились в файл обмена, при загрузке в базу-приемник они могут не сохраниться. По умолчанию платформа 1С при записи документа в режиме Запись (без проведения) очищает движения. Если же мы попытаемся провести документ при загрузке, система запустит стандартные алгоритмы проведения базы-приемника, что полностью перепишет наши загруженные движения.
Чтобы движения, перенесенные из файла, успешно записались в базу данных без вызова процедуры ОбработкаПроведения приемника, мы должны использовать специальный обработчик событий. Откроем ПКО документа и в обработчике события «После загрузки» (или «После загрузки объекта») напишем следующий код:
Если Объект.Проведен Тогда
Для каждого НаборДвижений Из Объект.Движения Цикл
НаборДвижений.Записывать = Истина;
КонецЦикла;
КонецЕсли;
Этот код заставляет платформу принудительно записать перенесенные из источника наборы записей. При этом сам документ получит статус Проведен = Истина, но реального перепроведения на стороне приемника не произойдет. Мы получим точные копии движений из базы-источника.
Рассмотрим ситуацию, когда перенос выполнен успешно, но в процессе работы пользователь в базе-приемнике решает зайти в перенесенный документ и нажать кнопку «Провести». В этот момент штатные алгоритмы конфигурации-приемника перезапишут загруженные движения. Если логика проведения в базах различается (например, из-за разных релизов конфигураций или специфических доработок), данные в отчетах гарантированно разойдутся.
Чтобы избежать этой проблемы, мы можем использовать механизм ручной корректировки. У большинства документов в типовых конфигурациях (включая 1С:Комплексная автоматизация) присутствует реквизит РучнаяКорректировка. Если при загрузке установить его в значение Истина, то при случайном перепроведении документа платформа не будет затирать наши движения. Реализовать это можно в том же обработчике «После загрузки»:
МетаданныеДокумента = Объект.Метаданные();
Если МетаданныеДокумента.Реквизиты.Найти("РучнаяКорректировка") <> Неопределено Тогда
Объект.РучнаяКорректировка = Истина;
КонецЕсли;
Если в вашей конфигурации (например, КА 2.4) обмен настроен через современный формат EnterpriseData (КД 3.0), то перенести движения «один в один» стандартными средствами не получится. Схемы формата EnterpriseData ориентированы на передачу бизнес-сущностей, а не физических таблиц базы данных. В них отсутствует структура для передачи движений документов (за исключением некоторых специфических объектов, таких как «ОперацияБух»).
При использовании КД 3.0 документы всегда проводятся на стороне приемника. Если для вас критически важно переносить движения без проведения, вам придется использовать классическую технологию КД 2.0 либо разрабатывать собственные схемы обмена на базе XML или JSON.
Если базы источника и приемника абсолютно идентичны, но вам требуется гибкая фильтрация данных при переносе (например, перенести данные только по одной организации и исключить помеченные на удаление или «лишние» элементы справочников), стандартная обработка ВыгрузкаЗагрузкаДанныхXML в своем базовом варианте может не подойти из-за отсутствия сложных фильтров.
В этом случае мы рекомендуем два альтернативных пути:
Таким образом, выбор конкретного метода зависит от архитектуры ваших баз данных и требований к дальнейшей работе с документами в базе-приемнике. Если перепроведение документов в приемнике не планируется, смело используйте перенос движений через КД 2.0 с установкой признака Записывать = Истина. В противном случае лучше настроить качественное проведение документов непосредственно на стороне базы-приемника.