При обмене данными между конфигурациями 1С:Управление нашей фирмой (УНФ 3.0) и 1С:Бухгалтерия (БП 3.0) пользователи часто сталкиваются с ситуацией, когда детализация по складам, зафиксированная в табличных частях документов УНФ, теряется при выгрузке в БП. — для этой задачи есть выгрузка документов и справочников из УНФ в БП. Типовой механизм синхронизации по умолчанию переносит такие данные на один обобщенный склад в Бухгалтерии, что затрудняет полноценный аналитический учет. Рассмотрим подробнее эту проблему и выясним возможные пути ее решения, основываясь на опыте пользователей и технических рекомендациях.
Первоначальная задача состоит в том, чтобы документы перемещения, поступления, расходные накладные, оприходования и прочие документы, где в УНФ указаны склады в табличных частях, корректно передавали эту аналитику в БП. Особенно актуально это становится, когда в рамках одного документа в табличной части используются разные склады.
Основная причина такого поведения типовой синхронизации кроется в настройке УНФ "Разрешить склады в табличных частях документа" (Настройки – Еще больше возможностей – Склад). Если эта опция активирована, УНФ предполагает более детальный учет на уровне строк документа, но типовые правила обмена с БП могут быть не адаптированы для передачи такой глубины аналитики. В результате, вместо детализации по каждому складу из табличной части, данные консолидируются на одном обобщенном складе, который указан в правилах обмена.
Для некоторых сценариев, когда использование разных складов в табличной части одного документа не является критичным или возможно пересмотреть бизнес-процессы, самым простым и эффективным решением может стать отключение соответствующей опции в УНФ. Разберем этот подход.
Расположение настройки: Откройте УНФ, перейдите в раздел Настройки, затем выберите Еще больше возможностей, найдите подраздел Склад. Здесь вы обнаружите опцию "Разрешить склады в табличных частях документа".
Механизм действия: Если эта опция отключена, склады в документах УНФ будут указываться в шапке документа, а не в табличных частях. В таком случае, типовая синхронизация сможет корректно передавать информацию о складе из шапки документа в БП, и данные будут прилетать на соответствующие склады.
Возможные ограничения: Необходимо учитывать, что система УНФ не позволит отключить эту опцию, если в базе уже существуют документы, в табличных частях которых использовались разные склады. В этом случае появится сообщение о невозможности изменения настройки. Прежде чем пытаться отключить опцию, возможно, потребуется распровести и/или скорректировать такие документы, чтобы все складские операции в них ссылались на один склад в шапке документа, или вовсе отказаться от использования разных складов в одной табличной части.
Пользователи подтверждают, что в случае, когда удалось отключить эту опцию и настроить синхронизацию УНФ с БП (например, через пункт "Другая программа" в настройках синхронизации), склады начали корректно передаваться в БП и вставать во всех документах по назначению.
Если отключение опции "Разрешить склады в табличных частях" невозможно из-за специфики бизнес-процессов, требующих указания разных складов в табличных частях одного документа, единственным надежным путем является доработка правил обмена данными. Это потребует участия специалиста 1С, знакомого с Конвертацией Данных (КД).
Почему необходима доработка: Типовые правила обмена между УНФ и БП, как правило, ориентированы на более простой сценарий учета складов, где склад указывается в шапке документа. При наличии складов в табличных частях, стандартные правила не содержат логики для детального сопоставления и переноса такой информации для каждой строки.
Где хранятся правила: Правила конвертации данных для обмена УНФ-БП могут быть расположены в различных местах в конфигурации, чаще всего это модули типа МенеджерОбменаЧерезУниверсальныйФормат или макеты узлов обмена. Для модификации этих правил специалисту потребуется выгрузить их, внести изменения и затем загрузить обратно.
Суть доработки: Наша задача заключается в изменении логики переноса данных таким образом, чтобы для каждого документа, где склады присутствуют в табличной части, система корректно определяла и переносила информацию о складе для каждой соответствующей строки в БП. Это может включать:
Изменение алгоритмов выгрузки/загрузки: В правилах для объектов, имеющих табличные части со складами (например, "РеализацияТоваровУслуг", "ПоступлениеТоваровУслуг"), необходимо будет изменить алгоритмы, отвечающие за перенос строк табличных частей. Вместо привязки к обобщенному складу, мы должны будем получать значение склада из каждой строки источника (УНФ) и передавать его в соответствующую строку приемника (БП).
Сопоставление реквизитов: Если в УНФ и БП наименования реквизитов, отвечающих за склад в табличной части, различаются (например, в УНФ это СкладПолучатель для продукции и Склад для материалов в документе "Производство", а в БП ожидается иной реквизит), потребуется настроить их правильное соответствие в правилах конвертации. Это гарантирует, что данные о складе из УНФ будут сопоставлены с нужным полем в БП.
Обработка особых случаев: Могут возникнуть ситуации, когда логика определения склада становится сложнее (например, если склад определяется косвенно). В таких случаях потребуется написать более сложные алгоритмы в правилах КД, чтобы учесть все нюансы.
Пример доработки: Представим, что у нас есть документ "Производство" в УНФ, где в табличной части продукции склад называется СкладПолучатель, а для материалов — Склад. В типовом обмене в БП эти склады могут не сопоставляться правильно. Специалист по КД должен будет внести изменения в правила выгрузки/загрузки документа "Производство" таким образом, чтобы при переносе каждой строки продукции или материалов, реквизит СкладПолучатель или Склад из УНФ сопоставлялся с соответствующим реквизитом склада в документе БП.
Доработка правил обмена является наиболее гибким и мощным решением, позволяющим учесть любые особенности учета и избежать потери аналитики.
Для внесения изменений в логику обмена без непосредственного изменения типовой конфигурации, что является крайне желательным подходом с точки зрения дальнейших обновлений, можно использовать расширения конфигурации. — для этого есть расширение для настройки синхронизации через EnterpriseData.
Преимущества расширений: Расширения позволяют дорабатывать функционал конфигурации (в том числе и механизмы обмена) без снятия ее с поддержки. Это значительно упрощает процесс обновления типовых решений, так как вам не придется каждый раз заново переносить свои доработки.
Как это работает: Специалист может создать расширение, которое будет содержать измененные правила обмена или логику, перехватывающую процесс выгрузки/загрузки данных для корректировки информации о складах. Например, можно переопределить методы выгрузки определенных объектов или добавить обработчики событий для корректировки данных непосредственно перед или после их сохранения.
Пример применения: Если бы мы, например, дорабатывали правила конвертации для обмена УНФ 1.6 с БП 3.0 для поддержки новых ставок НДС, мы могли бы инкапсулировать эти изменения в расширение, чтобы типовые правила обмена оставались неизменными.
Этот подход требует высокой квалификации разработчика, но обеспечивает максимальную гибкость и упрощает сопровождение системы в долгосрочной перспективе.
В случаях, когда доработка правил обмена кажется слишком сложной или требуется единоразовый перенос специфических данных, можно прибегнуть к написанию внешней обработки, которая будет использовать COM-соединение для прямого взаимодействия с обеими базами данных. Это своего рода "костыль", но он предоставляет полную свободу в определении логики переноса.
Принцип работы COM-соединения: COM-соединение позволяет одной базе 1С подключаться к другой базе как к внешнему объекту и выполнять операции с ее данными. Это дает возможность напрямую считывать информацию из УНФ и записывать ее в БП, минуя стандартные правила обмена.
Алгоритм действий:
Установление соединения: Внешняя обработка сначала устанавливает COM-соединение с базой УНФ и с базой БП.
Попытка
СоединениеУНФ = Новый COMОбъект("V83.Application"); // Или V82.Application для более старых платформ
СоединениеБП = Новый COMОбъект("V83.Application");
// Параметры подключения к базам
СтрокаПодключенияУНФ = "Srvr='localhost';Ref='UNF_Base';Usr='User';Pwd='Password';";
СтрокаПодключенияБП = "Srvr='localhost';Ref='BP_Base';Usr='User';Pwd='Password';";
СоединениеУНФ.Connect(СтрокаПодключенияУНФ);
СоединениеБП.Connect(СтрокаПодключенияБП);
Исключение
Сообщить("Ошибка подключения через COM: " + ОписаниеОшибки());
Возврат;
КонецПопытки;
Чтение данных из УНФ: Обработка выполняет запросы к базе УНФ для получения необходимых документов и информации о складах из их табличных частей. Например, мы можем получить список документов "Реализация товаров и услуг".
ВыборкаДокументовУНФ = СоединениеУНФ.Документы.РеализацияТоваровУслуг.Выбрать();
Пока ВыборкаДокументовУНФ.Следующий() Цикл
// Получаем объект документа
ДокУНФ = ВыборкаДокументовУНФ.ПолучитьОбъект();
// Обработка табличной части
Для Каждого СтрокаТЧУНФ Из ДокУНФ.Товары Цикл
СкладИзУНФ = СтрокаТЧУНФ.Склад; // Или другой реквизит склада
// ...
КонецЦикла;
КонецЦикла;
Поиск или создание документов в БП: Для каждого документа из УНФ, обработка пытается найти соответствующий документ в БП. Поиск может осуществляться по уникальному идентификатору (УИД), если он передается, или по номеру и дате документа.
// Поиск документа в БП по УИД
ДокБП = СоединениеБП.Документы.РеализацияТоваровУслуг.НайтиПоУникальномуИдентификатору(ДокУНФ.УникальныйИдентификатор());
Если ДокБП = Неопределено Тогда
// Если не нашли, ищем по номеру/дате или создаем новый
ДокБП = СоединениеБП.Документы.РеализацияТоваровУслуг.НайтиПоНомеру(ДокУНФ.Номер, ДокУНФ.Дата);
Если ДокБП = Неопределено Тогда
// Если все равно не нашли, создаем новый
ДокБП = СоединениеБП.Документы.РеализацияТоваровУслуг.СоздатьДокумент();
ДокБП.Дата = ДокУНФ.Дата;
ДокБП.Номер = ДокУНФ.Номер;
// Заполняем остальные реквизиты шапки
КонецЕсли;
КонецЕсли;
Заполнение данных в БП: После нахождения или создания документа в БП, обработка построчно заполняет его табличные части, перенося аналитику по складам из УНФ. Важно при этом сопоставить элементы справочников (номенклатуру, контрагентов, склады) между базами.
ДокБПОбъект = ДокБП.ПолучитьОбъект();
ДокБПОбъект.Товары.Очистить(); // Очищаем, чтобы заполнить заново
Для Каждого СтрокаТЧУНФ Из ДокУНФ.Товары Цикл
НоваяСтрокаБП = ДокБПОбъект.Товары.Добавить();
// Заполнение реквизитов строки
НоваяСтрокаБП.Номенклатура = СоединениеБП.Справочники.Номенклатура.НайтиПоКоду(СтрокаТЧУНФ.Номенклатура.Код);
НоваяСтрокаБП.Количество = СтрокаТЧУНФ.Количество;
НоваяСтрокаБП.Цена = СтрокаТЧУНФ.Цена;
// Здесь ключевое: передача склада
СкладБП = СоединениеБП.Справочники.Склады.НайтиПоКоду(СтрокаТЧУНФ.Склад.Код);
Если СкладБП <> Неопределено Тогда
НоваяСтрокаБП.Склад = СкладБП;
Иначе
// Обработка ситуации, если склад не найден
Сообщить("Склад '" + СтрокаТЧУНФ.Склад.Наименование + "' не найден в БП для документа " + ДокУНФ.Номер);
КонецЕсли;
КонецЦикла;
ДокБПОбъект.Записать(РежимЗаписиДокумента.Проведение); // Или РежимЗаписиДокумента.Запись
Закрытие соединения: После завершения всех операций соединения необходимо закрыть.
Преимущества и недостатки: Этот метод дает полный контроль над процессом переноса, но требует значительных усилий по разработке и отладке, а также не поддерживается базовыми конфигурациями 1С:Предприятие. — для решения этой задачи подойдёт перенос из УНФ в БП через COM.
Прежде чем приступать к каким-либо доработкам или сложным манипуляциям, важно убедиться, что базовые настройки синхронизации выполнены корректно. Это поможет исключить элементарные ошибки и сосредоточиться на специфической проблеме с аналитикой по складам.
Проверка общих параметров синхронизации: Убедитесь, что информация об организациях, учетной политике, параметрах учета, а также сопоставление основных справочников (номенклатура, контрагенты, склады) между УНФ и БП выполнены корректно. Каждый склад, используемый в УНФ, должен иметь свой идентичный аналог в БП.
Ограничения по данным: В правилах отправки и получения данных можно указать ограничения по видам документов и организациям. Убедитесь, что нет лишних ограничений, которые могли бы препятствовать передаче нужных документов.
Тестирование и отладка: Любые изменения в правилах обмена или разработка внешних обработок требуют тщательного тестирования. Рекомендуется сначала проводить все испытания на тестовых копиях баз данных, чтобы избежать повреждения рабочих данных. При выявлении ошибок используйте механизмы отладки для их устранения.
Таким образом, решение проблемы передачи аналитики по складам из табличных частей документов УНФ в БП зависит от конкретных условий и возможностей. Если возможно отказаться от использования разных складов в табличных частях, то отключение соответствующей опции в УНФ будет наиболее простым решением. В противном случае, потребуется квалифицированная доработка правил обмена или разработка специализированных обработок.