При обмене данными между различными конфигурациями 1С, такими как специализированная конфигурация для автосервиса (предположительно, 1С:Автосервис или аналогичная, далее АА 6) и типовой 1С:Бухгалтерией 3.0 (БП 3.0), часто возникает задача адаптации выгружаемых данных под логику принимающей системы. В нашей ситуации мы рассмотрим, как обеспечить условное определение значения статьи затрат в документе "Расход" (или аналогичном) в БП 3.0 на основе реквизита "Ремонт" из документа "Заказ-наряд" в АА 6.
Изначальная проблема заключается в том, что документ "Заказ-наряд" из АА 6 выгружается в БП как "Расход" со списком значений для статей затрат. Наша цель – сделать так, чтобы значение статьи затрат в документе "Расход" зависело от конкретного "вида ремонта", указанного в реквизите "Ремонт" исходного "Заказ-наряда". Если, например, вид ремонта "Плановый", то статья затрат должна быть одна, а если "Гарантийный" – другая.
Рассмотрим несколько подходов к решению этой задачи, каждый из которых имеет свои преимущества и особенности применения.
Наиболее распространенный, гибкий и правильный способ реализации условной логики при обмене данными между конфигурациями 1С – это настройка Правил конвертации объектов (ПКО) в конфигурации "Конвертация данных" (КД). Если ваш обмен уже настроен через универсальный формат, то, скорее всего, правила созданы именно там.
Для решения нашей задачи мы должны найти соответствующее ПКО, которое описывает конвертацию документа "Заказ-наряд" (источника) в документ "Расход" (приемника) или аналогичный документ в БП 3.0, который отражает расходы. В этом ПКО нам потребуется уделить внимание правилу конвертации для реквизита "СтатьяЗатрат" (или как он называется в вашей конфигурации БП 3.0).
В правилах конвертации свойств (реквизитов) в "Конвертации данных" предусмотрены специальные обработчики событий, которые позволяют добавить программный код для выполнения различных действий. Для нашей цели идеально подходят обработчики "Перед выгрузкой" или "При выгрузке" для реквизита "СтатьяЗатрат".
Разберем по шагам, как это можно реализовать:
Давайте посмотрим на пример кода, который может быть использован в обработчике "При выгрузке" для реквизита "СтатьяЗатрат":
// Параметры обработчика:
// ЗначениеИсточника - Ссылка на исходный объект (документ Заказ-наряд)
// ЗначениеПриемника - Значение, которое будет установлено в реквизит СтатьяЗатрат объекта-приемника
Если ЗначениеИсточника.Ремонт = "Плановый" Тогда
// Ищем статью затрат по наименованию в базе БП 3.0
ЗначениеПриемника = Справочники.СтатьиЗатрат.НайтиПоНаименованию("РемонтПлановый");
ИначеЕсли ЗначениеИсточника.Ремонт = "Гарантийный" Тогда
ЗначениеПриемника = Справочники.СтатьиЗатрат.НайтиПоНаименованию("РемонтГарантийный");
ИначеЕсли ЗначениеИсточника.Ремонт = "Внешний" Тогда
ЗначениеПриемника = Справочники.СтатьиЗатрат.НайтиПоНаименованию("СторонниеУслуги");
Иначе
// Если вид ремонта не определен или нужен вариант по умолчанию
ЗначениеПриемника = Справочники.СтатьиЗатрат.НайтиПоНаименованию("ПрочийРемонт");
КонецЕсли;
// Важно: убедитесь, что наименования статей затрат точно соответствуют
// тем, что существуют в справочнике "СтатьиЗатрат" в вашей базе БП 3.0.
// В более сложных случаях можно использовать поиск по коду, УИДу (GUID)
// или создавать вспомогательные функции для более надежного сопоставления.
В этом примере мы используем метод НайтиПоНаименованию() справочника СтатьиЗатрат. Критически важно, чтобы наименования статей затрат, которые вы указываете в коде, точно совпадали с наименованиями элементов в справочнике "Статьи затрат" вашей конфигурации БП 3.0. Если эти статьи еще не созданы в БП 3.0, их необходимо создать вручную или настроить их автоматическое создание при обмене, что является отдельной задачей.
Помимо программных обработчиков событий, в "Конвертации данных" можно использовать условные выражения и условия непосредственно в правилах конвертации свойств. Этот метод может быть удобнее для относительно простых случаев, когда нет сложной логики выбора.
Как это работает:
Например, мы создаем три правила для "СтатьяЗатрат":
ЗначениеИсточника.Ремонт = "Плановый". Значение: Ссылка на "РемонтПлановый".ЗначениеИсточника.Ремонт = "Гарантийный". Значение: Ссылка на "РемонтГарантийный".Система будет перебирать правила, и как только условие будет выполнено, применит соответствующее правило. Однако для более сложной или динамической логики, включающей поиск по справочникам, программный код в обработчиках событий остается более мощным инструментом.
В некоторых случаях (например, если вы не хотите модифицировать типовые правила конвертации, чтобы не нарушать их обновляемость, или если универсальный формат обмена подразумевает более глубокую интеграцию), можно использовать расширения для модификации логики обмена. Этот подход был предложен одним из участников форума.
Этот метод актуален, когда обмен настроен таким образом, что данные перед выгрузкой обрабатываются в общих модулях конфигурации-источника, использующих универсальный формат обмена.
Разберем суть подхода:
МенеджерОбменаЧерезУниверсальныйФормат (или аналогичный, который отвечает за подготовку данных к выгрузке).ПОД_Документ_ЗаказНаряд_Отправка_ПриОбработке (где "ПОД" может означать "ПодготовкаОбъектаДляДанных"). Название может отличаться в вашей конфигурации, поэтому потребуется анализ существующего кода обмена.Пример (псевдокод) того, что может быть сделано в таком обработчике:
// В расширении, в заимствованном обработчике ПОД_Документ_ЗаказНаряд_Отправка_ПриОбработке
// Допустим, параметры обработчика включают:
// ОбъектИсточник - исходный документ Заказ-наряд
// СтруктураДанныхДляВыгрузки - структура, которая будет передана в универсальный формат
Если ОбъектИсточник.Ремонт = "Плановый" Тогда
СтруктураДанныхДляВыгрузки.Вставить("СтатьяЗатратУсловная", "РемонтПлановый_GUID_из_БП");
ИначеЕсли ОбъектИсточник.Ремонт = "Гарантийный" Тогда
СтруктураДанныхДляВыгрузки.Вставить("СтатьяЗатратУсловная", "РемонтГарантийный_GUID_из_БП");
Иначе
СтруктураДанныхДляВыгрузки.Вставить("СтатьяЗатратУсловная", "ПрочийРемонт_GUID_из_БП");
КонецЕсли;
// Затем в Правилах конвертации объектов (ПКО) нужно будет настроить
// конвертацию этого нового реквизита "СтатьяЗатратУсловная" в реквизит "СтатьяЗатрат"
// документа "Расход" в БП 3.0. При этом, скорее всего, потребуется использовать
// поиск объекта по GUID или наименованию в приемнике.
Этот способ требует более глубокого понимания архитектуры обмена через универсальный формат и того, как именно он использует общие модули для подготовки данных. Важно помнить, что если вы изменяете данные на этом этапе, то эти изменения должны быть учтены в соответствующих ПКО в "Конвертации данных", чтобы они корректно интерпретировались в принимающей конфигурации.
Один из участников форума упомянул "Правила регистрации". Важно понимать, что Правила регистрации объектов в конфигурации "Конвертация данных" используются в основном для определения того, какие объекты и при каких условиях будут зарегистрированы для обмена, а не для преобразования их реквизитов.
Например, вы можете настроить правило регистрации так, чтобы документ "Заказ-наряд" выгружался только в том случае, если его реквизит "Ремонт" имеет определенное значение (например, "Плановый"). В этом случае документы с другими видами ремонта просто не будут выгружаться.
Однако, для нашей задачи, которая состоит в том, чтобы все заказ-наряды выгружались, но с разной статьей затрат в зависимости от вида ремонта, правила регистрации напрямую не подходят. Они позволяют решить, выгружать ли документ, но не как его преобразовать после выгрузки.
В процессе обсуждения возник важный вопрос: "есть реквизит 'Ремонт' В БП в метаданных есть такой реквизит?". Ответ был "Вроде нет".
Это критический момент. Если реквизит "Ремонт" или его аналог не существует в метаданных БП 3.0, это означает следующее:
Таким образом, если значение вида ремонта требуется только как условие для выбора статьи затрат и не несет самостоятельной аналитической нагрузки в БП 3.0, то создавать для него отдельный реквизит в БП не нужно. Если же в БП требуется аналитика по видам ремонта, то придется модифицировать метаданные БП 3.0 (создать новый реквизит в документе "Расход" или использовать аналитику по субконто) и настроить его конвертацию.
В случаях, когда логика сопоставления между видами ремонта и статьями затрат становится слишком обширной, сложной или часто меняющейся, мы можем использовать вспомогательные справочники. Например, можно создать в одной или обеих конфигурациях справочник "СопоставлениеВидовРемонтаИСтатейЗатрат".
В таком справочнике можно хранить пары значений:
Тогда в правилах конвертации (в обработчике "При выгрузке") мы будем обращаться к этому справочнику сопоставлений, передавая в него вид ремонта из исходного документа и получая соответствующую статью затрат для приемника. Этот подход делает систему более гибкой, позволяя изменять правила сопоставления без перепрограммирования обмена.
Мы должны всегда стремиться максимально использовать возможности конфигурации "Конвертация данных" и типовых механизмов синхронизации. Изменение типовых механизмов обмена (например, через расширения) всегда должно быть обдуманным шагом, так как это может повлиять на процесс обновления конфигураций. Если типовой обмен уже настроен, то чаще всего проще и безопаснее внести изменения именно в ПКО, чем модифицировать код общих модулей.
В заключение, задача условного определения статьи затрат при обмене данными – это типичная проблема, которая эффективно решается с помощью гибких инструментов "Конвертации данных". Выбор между обработчиками событий, условными выражениями или даже расширениями зависит от конкретных требований, сложности логики и политики поддержки вашей системы.