В конфигурации «Бухгалтерия государственного учреждения 2.0» (БГУ 2.0) разработчики часто сталкиваются с ситуацией, когда в табличной части документа (например, ЗаявкаНаКассовыйРасход) на форме отображаются поля «Договор», «Контрагент» или «Вид затрат», но при попытке найти их в метаданных объекта в конфигураторе они отсутствуют. Это вызывает логичный вопрос: как программно обращаться к таким полям и заполнять их, особенно при создании документа на основании.
В данной статье мы разберем внутреннее устройство подсистемы типовых операций, выясним, где физически хранятся эти данные, и научимся ими управлять. Для контроля корректности таких доработок и поиска ошибок в проводках удобно применять автоматическую выверку бухгалтерских данных между базами 1С.
Разберем природу появления этих реквизитов. В БГУ 2.0 реализован механизм типовых операций. Это гибкая система, которая позволяет настраивать проводки и аналитику документа без изменения программного кода. Поскольку для разных операций могут требоваться разные наборы аналитики (субконто), добавлять их все как жесткие реквизиты в табличную часть объекта было бы нерационально.
Проанализируем ситуацию: когда пользователь выбирает определенную типовую операцию в документе, система динамически «достраивает» форму. Она добавляет программные реквизиты и элементы формы, связывая их с параметрами выбранной операции. Именно поэтому в отладчике мы видим странные имена вида БухгалтерскиеОперации_GUID_Контрагент.
Многие начинающие разработчики совершают ошибку, полагая, что данные живут только в форме. Выясним причину их сохранения между сеансами. На самом деле, информация записывается в специальные регистры сведений. Основным местом хранения для строковых данных табличных частей является регистр ЗначенияКолонокДополнительныхТабличныхЧастей.
Рассмотрим структуру этого регистра:
Если нам нужно заполнить эти значения непосредственно в открытой форме документа (например, при изменении какого-то другого поля), мы можем обращаться к ним напрямую через объект строки. Рассмотрим пример кода, который можно использовать в модуле формы:
// Предположим, мы находимся в обработчике события или процедуре формы
Для Каждого СтрокаТЧ Из Объект.РасшифровкаПлатежа Цикл
// Используем точное имя динамического реквизита, полученное через табло или отладчик
СтрокаТЧ.БухгалтерскиеОперации_8951d039_ec90_11e8_8085_494e53000030_Контрагент = Объект.Контрагент;
СтрокаТЧ.БухгалтерскиеОперации_c13fd2e5_eefa_11e8_af65_2c56dc9bbaca_Договор = Объект.Договор;
КонецЦикла;
Важный нюанс: Этот способ сработает только в том случае, если форма уже инициализирована и типовая операция выбрана. Если вы попытаетесь сделать это до того, как система построила динамические колонки, возникнет ошибка «Поле объекта не обнаружено».
Рассмотрим более сложную, но правильную ситуацию: создание документа на основании другого (например, из Заявления на выдачу аванса). В этом случае формы еще нет, и мы работаем в процедуре ОбработкаЗаполнения в модуле объекта.
Поскольку реквизитов в самом объекте нет, нам нужно подготовить данные так, чтобы форма при открытии смогла их подхватить. Для этого в БГУ 2.0 в документах часто предусмотрена скрытая табличная часть ПараметрыОперации или аналогичные механизмы кэширования. Однако самым надежным методом является использование программного интерфейса подсистемы типовых операций.
Проанализируем алгоритм действий:
ТиповаяОперация. Без этого система не поймет, какие параметры нужно инициализировать.ИдентификаторСтроки для каждой строки вашей основной табличной части (если он еще не заполнен).ЗначенияКолонокДополнительныхТабличныхЧастей или заполнить служебную структуру параметров, которую подхватит стандартный механизм БГУ при первом сохранении/открытии.Посмотрим на ситуацию, когда нам нужно получить значение договора из закрытого документа. Как мы уже выяснили, обращаться к ДокументОбъект.РасшифровкаПлатежа[0].Договор бесполезно. Нам поможет запрос к регистру сведений. Разберем пример запроса:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Регистр.Значение КАК ЗначениеПараметра
|ИЗ
| РегистрСведений.ЗначенияКолонокДополнительныхТабличныхЧастей КАК Регистр
|ГДЕ
| Регистр.Объект = &СсылкаНаДокумент
| И Регистр.ИдентификаторСтроки = &ИдентификаторСтроки";
Запрос.УстановитьПараметр("СсылкаНаДокумент", СсылкаНаЗаявку);
Запрос.УстановитьПараметр("ИдентификаторСтроки", КлючСтрокиТЧ);
// Также желательно добавить фильтр по самому параметру (GUID в имени поля)
При работе с типовыми операциями в БГУ 2.0 следует придерживаться следующих правил, а перед внесением массовых программных правок использовать инструмент для автоматического архивирования и тестирования баз 1С:
БухгалтерскиеОперации_GUID... могут отличаться в разных базах, если типовые операции создавались или загружались по-разному. Лучше программно находить нужный GUID параметра через справочник ПараметрыТиповыхОпераций по его коду или предопределенному имени.ТиповыеОперацииБГУ или ТиповыеОперацииКлиентСервер), которые содержат функции УстановитьЗначениеПараметра(). Это гораздо безопаснее, чем прямая запись в регистры.ИдентификаторСтроки. Если вы копируете строки программно, не забывайте генерировать новый уникальный идентификатор, иначе данные «перепутаются» или исчезнут.Таким образом, мы выяснили, что «невидимые» поля в БГУ 2.0 — это результат работы динамического интерфейса, базирующегося на настройках типовых операций и хранящего свои данные во внешних по отношению к документу регистрах. Использование правильных методов обращения к этим данным позволит вам корректно автоматизировать бизнес-процессы в бюджетных учреждениях. Если в ходе автоматизации потребуется перенос данных между базами с несовпадающими ссылками, можно задействовать обработку для переноса данных между похожими конфигурациями 1С с поиском по произвольным полям.